home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
8_4_03.tro
< prev
next >
Wrap
Text File
|
1991-12-22
|
130KB
|
6,030 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v'|.5i'
.ce 1000
ANNEX\ A
.ce 0
.ce 1000
(to Recommendation X.208)
.EF '% Fascicle\ VIII.4\ \(em\ Rec.\ X.208''
.OF '''Fascicle\ VIII.4\ \(em\ Rec.\ X.208 %'
.sp 9p
.RT
.ce 0
.ce 1000
\fBThe\fR
\fBmacro notation\fR
.sp 1P
.RT
.ce 0
.LP
A.1
\fIIntroduction\fR
.sp 1P
.RT
.PP
A mechanism is provided within ASN.1 for the user of ASN.1 to
define a new notation with which he can then construct and reference ASN.1
types or specify values of types. The new notation is defined using the
notation \*QMacroDefinition\*U. A \*QMacroDefinition\*U simultaneously
specifies a new notation for constructing and referencing a type and also
a new notation for
specifying a value. (See \(sc\ I.3 for an illustration of the use of the macro
notation.)
.PP
With a \*QMacroDefinition\*U the ASN.1 user specifies the new notation
by means of a set of productions in a manner similar to that of this
Recommendation. The writer of the macro definition;
.RT
.LP
a)
specifies the complete syntax to be used for defining all
types supported by the macro (this syntax specification is invoked
for syntax analysis by any occurrence of the macro name in the ASN.1
type notation); and
.LP
b)
specifies the complete syntax to be used for a value of one
of these types (this syntax specification is invoked for syntax
analysis whenever a value of the macro type is expected); and
.LP
c)
specifies, as the value of a standard ASN.1 type (of
arbitrary complexity), the resulting type and value for all instances
of the macro value notation.
.PP
An instance of the syntax defined by the macro definition can
contain instances of types or values (using the standard ASN.1 notation).
These types or values (appearing in the use of macro notation) can be associated,
for the duration of the syntax analysis, with a \fBlocal type reference\fR
or a \fBlocal value reference\fR by appropriate statements in the macro
definition. It is also possible to embed, within the macro definition,
standard ASN.1 type
.PP
assignments. These assignments become active when the associated syntactic
category is matched against an item or items in the instance of the new
notation being analysed. Their lifetime is limited to that of the analysis.
.PP
When analysing a value in the new notation, assignments made during
analysis of the corresponding type notation are available. Such analysis is
considered to logically precede analysis of every instance of the value
notation.
.PP
The resulting type and value of an instance of use of the new value
notation is determined by the value (and the type of the value) finally
assigned to the distinguished local value reference identified by the keyword
item VALUE, according to the processing of the macrodefinition for the
new type notation followed by that for the new value notation.
.PP
Each \*QMacroDefinition\*U defines a notation (a syntax) for type
definition and a notation (a syntax) for value definition. The ASN.1 type
which is defined by an instance of the new type notation may, but need
not, depend on the instance of the value notation with which the type is
associated. To this extent, the use of the new type notation is similar
to a CHOICE\ \(em\ the tag is
indeterminate. Thus the new notation cannot in this case be used in places
where a known tag is required, nor can it be implicitly tagged.
.RT
.sp 1P
.LP
A.2
\fIExtensions to the ASN.1 character set and items\fR
.sp 9p
.RT
.PP
The characters | and > are used in the macro notation.
.PP
The items specified in the following subclauses are also used.
.bp
.RT
.sp 1P
.LP
A.2.1
\fIMacroreference\fR
.sp 9p
.RT
.PP
Name of item\ \(em\ macroreference
.PP
A <<macroreference>> shall consist of the sequence of characters
specified for a \*Qtypereference\*U in \(sc\ 8.2, except that all characters
shall be in upper\(hycase. Within a single module, the same sequence of
characters shall
not be used for both a typereference and a macroreference.
.RT
.sp 1P
.LP
A.2.2
\fIProductionreference\fR
.sp 9p
.RT
.PP
Name of item\ \(em\ productionreference
.PP
A <<productionreference>> shall consist of the sequence of characters
specified for a \*Qtypereference\*U in \(sc\ 8.2.
.RT
.sp 1P
.LP
A.2.3
\fILocaltypereference\fR
.sp 9p
.RT
.PP
Name of item\ \(em\ localtypereference
.PP
A \*Qlocaltypereference\*U shall consist of the sequence of characters
specified for a \*Qtypereference\*U in \(sc\ 8.2. A \*Qlocaltypereference\*U
is used as an identifier for types which are recognized during syntax analysis
of an instance of the new type or value notation.
.RT
.sp 1P
.LP
A.2.4
\fILocalvaluereference\fR
.sp 9p
.RT
.PP
Name of item\ \(em\ localvaluereference
.PP
A \*Qlocalvaluereference\*U shall consist of the sequence of characters
specified for a \*Qvaluereference\*U in \(sc\ 8.2. A \*Qlocalvaluereference\*U
is used as an identifier for values which are recognized during syntax
analysis of an
instance of the new type or value notation.
.RT
.sp 1P
.LP
A.2.5
\fIAlternation item\fR
.sp 9p
.RT
.PP
Name of item\ \(em\ \*Q\ |\ \*U
.PP
This item shall consist of the single character\ |
.
.RT
.sp 1P
.LP
A.2.6
\fIDefinition terminator item\fR
.sp 9p
.RT
.PP
Name of item\ \(em\ >
.PP
This item shall consist of the single character\ >.
.PP
\fINote\fR \ \(em\ The item < for the start of definitions is defined in
\(sc\ 8.13.
.RT
.sp 1P
.LP
A.2.7
\fISyntactic terminal item\fR
.sp 9p
.RT
.PP
Name of item\ \(em\ astring
.PP
An \*Qastring\*U shall consist of an arbitrary number (possibly zero) of
characters from the ASN.1 character set (see \(sc\ 7), surrounded by\ \*U.
The
character\ \*U shall be represented in an \*Qastring\*U by a pair of\ \*U.
.PP
\fINote\fR \ \(em\ Use of \*Qastring\*U in the macronotation specifies the
occurrence, at the corresponding point in the syntax being analysed, of the
characters enclosed in quotation marks\ (\*U).
.bp
.RT
.ce
\fBH.T. [T8.208]\fR
.ce
TABLE\ 8/X.208
.ce
\fBSequence specified by items\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(48p) | cw(72p) .
Item name Defining clause
_
.T&
lw(48p) | lw(72p) .
\*Qstring\*U any sequence of characters
.T&
lw(48p) | lw(72p) .
\*Qidentifier\*U 8.3\ \(em\ Identifiers
.T&
lw(48p) | lw(72p) .
\*Qnumber\*U 8.8\ \(em\ Numbers
.T&
lw(48p) | lw(72p) .
\*Qempty\*U 8.7\ \(em\ Empty
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 8/X.208 [T8.208], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 2
A.2.8
\fISyntactic category keywork items\fR
.sp 9p
.RT
.LP
.sp 1
Names of items:
\*Qstring\*U
.LP
\*Qidentifier\*U
.LP
\*Qnumber\*U
.LP
\*Qempty\*U
.PP
.sp 1
Items with the above names shall consist (in the macronotation) of the
sequences of characters in the name, excluding the quotation symbols\ (\*U).
These items are used in the macro notation to specify the occurrence, in
an
instance of the new notation, of certain sequences of characters. The sequences
in the new notation specified by each item are given in Table\ 8/X.208
by
reference to a clause in this Recommendation which defines the sequence of
characters appearing in the new notation.
.PP
\fINote\fR \ \(em\ The macro notation does not support the distinction
between identifiers and references based on the case of the initial letter.
This is for historical reasons.
.RT
.sp 1P
.LP
A.2.9
\fIAdditional keyword items\fR
.sp 9p
.RT
.LP
.sp 1
Names of items:
MACRO
.LP
TYPE
.LP
NOTATION
.LP
VALUE
.LP
value
.LP
type
.PP
.sp 1
Items with the above names shall consist of the sequence of
characters in the name.
.PP
The items specified in clauses \(sc\ A.2.2 to \(sc\ A.2.4 inclusive shall
not be one of the \(sc\ A.2.9 sequences, except when used as specified
below.
.PP
The keyword \*QMACRO\*U shall be used to introduce a macro definition.
The keyword \*QTYPE
NOTATION\*U shall be used as the name of the production which
defines the new type notation. The keyword \*QVALUE NOTATION\*U shall be
used as
the name of the production which defines the new value notation. The
.PP
keyword \*QVALUE\*U shall be used as the \*Qlocalvaluereference\*U to which the
resulting value is assigned. The keyword \*Qvalue\*U shall be used to specify
that each instance of the new notation contains at this point, using standard
ASN.1 notation, some value of a type (specified in the macro definition).
The keyword \*Qtype\*U shall be used to specify that each instance of the
new notation contains at this point, using standard ASN.1 notation, some
\*QType\*U.
.bp
.RT
.sp 2P
.LP
A.3
\fIMacro definition notation\fR
.sp 1P
.RT
.PP
A.3.1
A macro shall be defined using the notation \*QMacroDefinition\*U:
.sp 9p
.RT
.LP
MacroDefinition\ ::=
.LP
macroreference
.LP
MACRO
.LP
\*Q::=\*U
.LP
MacroSubstance
.LP
MacroSubstance\ ::=
.LP
BEGIN MacroBody END\ |
.LP
macroreference\ |
.LP
Externalmacroreference
.LP
MacroBody\ ::=
.LP
TypeProduction
.LP
ValueProduction
.LP
SupportingProductions
.LP
TypeProduction\ ::=
.LP
TYPE NOTATION
.LP
\*Q::=\*U
.LP
MacroAlternativeList
.LP
ValueProduction\ ::=
.LP
VALUE NOTATION
.LP
\*Q::=\*U
.LP
MacroAlternativeList
.LP
SupportingProduction\ ::=
.LP
ProductionList\ |
.LP
empty
.LP
ProductionList\ ::=
.LP
Production\ |
.LP
ProductionList Production
.LP
Production\ ::=
.LP
productionreference
.LP
\*Q::=\*U
.LP
MacroAlternativeList
.LP
Externalmacroreference\ ::=
.LP
modulereference\|.\|macroreference
.PP
\fINote\fR \ \(em\ It is intended that one macro definition be permitted
to reference (i.e.,\ use) other macros. Ensuring that the notation permits
this is for further study.
.PP
A.3.2
If the \*Qmacroreference\*U alternative of \*QMacroSubstance\*U is chosen,
then the module containing the macro definition shall either:
.sp 9p
.RT
.LP
a)
contain another macro definition defining that
\*Qmacroreference\*U; or
.LP
b)
contain the \*Qmacroreference\*U in its \*QSymbolsImported\*U.
.PP
A.3.3
If the \*QExternalmacroreference\*U alternative of \*QMacroSubstance\*U
is chosen, then the module denoted by \*Qmodulereference\*U shall contain
a macro
definition defining the \*Qmacroreference\*U. The associated definition is then
also associated with the \*Qmacroreference\*U being defined.
.bp
.sp 9p
.RT
.PP
A.3.4
The chain of definitions which can arise from repeated
applications of the rules of \(sc\ A.3.2 to \(sc\ A.3.3 shall terminate with a
\*QMacroDefinition\*U which uses the \*QBEGIN MacroBody END\*U alternative
and it is
that \*QMacroBody\*U which defines the type and value notation for the
macro being defined.
.PP
A.3.5
Each \*Qproductionreference\*U which occurs in a \*QSymbolDefn\*U (see
\(sc\ A.3.9) shall occur exactly once as the first item in a \*QProduction\*U.
.PP
A.3.6
Each instance of the new type notation shall commence with the
sequence of characters in the \*Qmacroreference\*U, followed by one of the
sequences of characters referenced by \*QTYPE NOTATION\*U after applying the
productions specified in the macro definition.
.PP
A.3.7
Each instance of the new value notation shall consist of one of
the sequences of characters referenced by \*QVALUE NOTATION\*U after applying
the productions specified in the macro definition.
.PP
A.3.8
The \*QMacroAlternativeList\*U in a production specifies the possible sets
of character sequences referenced by the production. It is specified by:
.LP
MacroAlternative List\ ::=
.LP
MacroAlternative\ |
.LP
MacroAlternativeList\ \*Q\ |\ \*U MacroAlternative
.PP
The set of character sequences referenced by the
\*QMacroAlternativeList\*U consists of all the character sequences which are
referenced by any of the \*QMacroAlternative\*U productions in the
\*QMacroAlternativeList\*U.
.PP
A.3.9
The notation for a \*QMacroAlternative\*U shall be:
.sp 9p
.RT
.LP
MacroAlternative\ ::=\ SymbolList
.LP
SymbolList\ ::=
.LP
SymbolElement
|
.LP
SymbolList SymbolElement
.LP
SymbolElement\ ::=
.LP
SymbolDefn
|
.LP
EmbeddedDefinitions
.LP
SymbolDefn\ ::=
.LP
astring
|
.LP
productionreference
|
.LP
\*Qstring\*U
|
.LP
\*Qidentifier\*U
|
.LP
\*Qnumber\*U
|
.LP
\*Qempty\*U
|
.LP
type
|
.LP
type(localtypereference)
|
.LP
value(MacroType)
|
.LP
value(localvaluereference MacroType)
|
.LP
value(VALUE MacroType)
.LP
MacroType\ ::=\ localtypereference
|
.LP
Type
.PP
\fINote\fR \ \(em\ When in a macro, any \*QMacroType\*U defined in that macro
can appear at any point in which ASN.1 specifies a \*QType\*U.
.PP
A \*QMacroAlternative\*U references all characters strings which are
formed by taking any of the character strings referenced by the first
\*QSymbolDefn\*U in the \*QSymbolList\*U, followed by any one of the character
strings referenced by the second \*QSymbolDefn\*U in the \*QSymbolList\*U,
and so on, up to and including the last \*QSymbolDefn\*U in the \*QSymbolList\*U.
.PP
\fINote\fR \ \(em\ The \*QEmbeddedDefinitions\*U (if any) play no direct
part in
determining these strings.
.bp
.RT
.PP
A.3.10
An \*Qastring\*U references the sequence of characters in the
\*Qastring\*U without the enclosing pair of\ \*U.
.sp 9p
.RT
.PP
A.3.11
A \*Qproductionreference\*U references any sequence of characters
specified by the \*QProduction\*U it identifies.
.PP
A.3.12
The sequences of characters referenced by the next four
alternatives for \*QSymbolDefn\*U are specified in Table\ 8/X.208.
.PP
\fINote\fR \ \(em\ The sequences of characters referenced by the \*Qstring\*U
should be terminated in an instance of the macro notation by the appearance
of a sequence referenced by the next \*QSymbolDefn\*U in the \*QSymbolList\*U.
.PP
A.3.13
A \*Qtype\*U references any sequence of symbols which forms a \*QType\*U
notation as specified in \(sc\ 12.1.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ The \*QDefinedType\*U of \(sc\ 12.1 may in this case
contain a
\*Qlocaltypereference\*U referencing a type defined in the macro notation.
.PP
A.3.14
A \*Qtype(localtypereference)\*U references any sequence of symbols which
forms a \*QType\*U as specified in \(sc\ 12.1, but in addition assigns
that type to the \*Qlocaltypereference\*U. A later assignment may occur
to the same
\*Qlocaltypereference\*U.
.sp 9p
.RT
.PP
A.3.15
A \*Qvalue(MacroType)\*U references any sequence of symbols which
forms a \*QValue\*U notation (as specified in \(sc\ 12.7) for the type
specified by the \*QMacro Type\*U.
.PP
A.3.16
A \*Qvalue(localvaluereference MacroType)\*U references any sequence of
symbols which forms a \*QValue\*U notation (as specified in \(sc\ 12.7)
for the type specified by \*QMacroType\*U, but in addition assigns the
value specified by the
value notation to the \*Qlocalvaluereference\*U. A later assignment may
occur to
the \*Qlocalvaluereference\*U.
.PP
A.3.17
A \*Qvalue(VALUE MacroType)\*U references any sequence of symbols
which forms a \*QValue\*U notation (as specified in \(sc\ 12.7) for the
type specified by \*QMacroType\*U, but in addition returns the value as
the value specified by the value notation. The type of the value returned
is the type referenced by
MacroType.
.PP
A.3.18
Precisely one assignment to VALUE (as specified in \(sc\ A.3.17 or in \(sc\
A.3.19) occurs in the analysis of any correct instance of the new value
notation.
.PP
A.3.19
The notation for an \*QEmbeddedDefinitions\*U shall be:
.LP
EmbeddedDefinitions\ ::=
.LP
<EmbeddedDefinitionList>
.LP
EmbeddedDefinitionList\ ::=
.LP
EmbeddedDefinition\ |
.LP
EmbeddedDefinitionList
.LP
EmbeddedDefinition
.LP
EmbeddedDefinition\ ::=
.LP
LocalTypeassignment\ |
.LP
LocalValueassignment
.LP
LocalTypeassignment\ ::=
.LP
localtypereference
.LP
\*Q::=\*U
.LP
MacroType
.LP
LocalValueassignment\ ::=
.LP
localvaluereference
.LP
MacroType
.LP
\*Q::=\*U
.LP
MacroValue
.LP
MacroValue\ ::=
.LP
Value\ |
.LP
localvaluereference
.bp
.PP
The assignment of a \*QMacroType\*U to a \*Qlocaltypereference\*U (or of
a \*QMacroValue\*U to a \*Qlocalvaluereference\*U) within an \*QEmbeddedDefinitions\*U
takes effect during the syntax analysis of an instance of the new notation
at the
time when the \*QEmbeddedDefinitions\*U is encountered, and persists until
redefinition of the \*Qlocaltypereference\*U or \*Qlocalvaluereference\*U
occurs.
.PP
\fINote\ 1\fR \ \(em\ The use of the associated \*Qlocaltypereference\*U or
\*Qlocalvaluereference\*U elsewhere in the \*QAlternative\*U implies assumptions
on the nature of the parsing algorithm. Such assumptions should be indicated
by
comment. For example, use of the \*Qlocaltypereference\*U textually following
the \*QEmbeddedDefinitions\*U implies a left to right parse.
.PP
\fINote\ 2\fR \ \(em\ The \*Qlocalvaluereference\*U \*QVALUE\*U may be
assigned a value either by the \*Qvalue (VALUE MacroType)\*U construct
or by an
\*QEmbeddedDefinition\*U. In both cases, the value is returned, as specified
in
\(sc\ A.3.17.
.RT
.sp 1P
.LP
A.4
\fIUse of the new notation\fR
.sp 9p
.RT
.PP
Whenever a \*QType\*U (or \*QValue\*U) notation is called for by this
Recommendation, an instance of the type notation (or value notation) defined
by a macro may be used, provided that the macro is either:
.RT
.LP
a)
defined within the same module; or
.LP
b)
imported into the module, by means of the appearance of the
\*Qmacroreference\*U in the \*QSymbolsImported\*U of the module.
.PP
To allow the latter possibility, a \*Qmacroreference\*U can appear as a
\*QSymbol\*U in \(sc\ 9.1.
.PP
\fINote\ 1\fR \ \(em\ This extension to the standard ASN.1 notation is
not shown in the body of this Recommendation.
.PP
\fINote\ 2\fR \ \(em\ It is possible to construct modules including sequences
of type assignment and macro definitions which make parsing of the value
syntax in DEFAULT values arbitrarily complex.
\v'1P'
.RT
.ce 1000
ANNEX\ B
.ce 0
.ce 1000
(to Recommendation X.208)
.sp 9p
.RT
.ce 0
.ce 1000
\fBISO assignment of OBJECT IDENTIFIER component values\fR
.sp 1P
.RT
.ce 0
.PP
B.1
Three arcs are specified from the root node. The assignment of
values and identifiers, and the authority for assignment of subsequent
component values, are as follows:
.sp 1P
.RT
.LP
\fBValue\fR
\fBIdentifier\fR \fBAuthority for subsequent\fR \fBassignments\fR
.LP
0
ccitt
CCITT
.LP
1
iso
ISO
.LP
2
joint\(hyiso\(hyccitt
See Annex D
.PP
\fINote\fR \ \(em\ The remainder of this annex concerns itself only with
ISO assignment of values.
.PP
B.2
The identifiers \*Qccitt\*U, \*Qiso\*U and \*Qjoint\(hyiso\(hyccitt\*U,
assigned
above, may each be used as a \*UNameForm\*U.
.sp 9p
.RT
.PP
B.3
Four arcs are specified from the node identified by \*Qiso\*U. The
assignment of values and identifiers is
.LP
\fBValue\fR
\fBIdentifier\fR
\fBAuthority for subsequent\fR \fBassignments\fR
.LP
0
standard
See \(sc B.4
.LP
1
registration\(hyauthority
See \(sc B.5
.LP
2
member\(hybody
See \(sc B.6
.LP
3
identified\(hyorganization
See \(sc B.7
.PP
These identifiers may be used as a \*QNameForm\*U.
.bp
.PP
B.4
The arcs below \*Qstandard\*U shall each have the value of the number of
an International Standard. Where the International Standard is multi\(hypart,
there shall be an additional arc for the part number, unless this is
specifically excluded in the text of the International Standard. Further
arcs shall have values as defined in that International Standard.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ If a non\(hymultipart International Standard allocates
object identifiers, and subsequently becomes a multipart International
Standard, it shall continue to allocate object identifiers as if it were a
single part International Standard.
.PP
B.5
The arcs below \*Qregistration authority\*U are reserved for an
addendum to this Recommendation which will be progressed alongide the
establishment of procedures for the identification of specific OSI Registration
Authorities.
.sp 9p
.RT
.PP
B.6
The arcs immediately below \*Qmember\(hybody\*U shall have values of
three digit numeric country code, as specified in ISO\ 3166, that identifies
the ISO Member Body in that country (see Note). The \*QNameForm\*U of object
identifier component is not permitted with these identifiers. Arcs below
the \*Qcountry
code\*U are not defined in this Recommendation.
.PP
\fINote\fR \ \(em\ The existence of a country code in ISO 3166 does not
necessarily imply that there is an ISO Member Body representing that country
or that the ISO Member Body for that country administers a scheme for the
allocation of object identifier components.
.PP
B.7
The arcs immediately below \*Qidentified\(hyorganization\*U shall have
values of an International Code Designator (ICD) allocated by the Registration
Authority for ISO\ 6523 that identify an issuing organization specifically
registered by the authority as allocating object identifier components (see
Notes\ 1 and\ 2). The arcs immediately below the ICD shall have values of an
\*Qorganization code\*U allocated by the issuing organization in accordance
with
ISO\ 6523. Arcs below \*Qorganization code\*U are not defined by this Recommendation
(see Note\ 3).
.sp 9p
.RT
.PP
\fINote\ 1\fR \ \(em\ The requirement that issuing organizations are recorded
by the Registration Authority for ISO\ 6523 as allocating organization
codes for the purpose of object identifier components ensures that only
numerical values in accordance with this Recommendation are allocated.
.PP
\fINote\ 2\fR \ \(em\ The declaration that an issuing organization allocates
organization codes for the purpose of object identifier components does not
preclude the use of these codes for other purposes.
.PP
\fINote\ 3\fR \ \(em\ It is assumed that the organizations identified by the
\*Qorganization code\*U will define further arcs in such a way as to ensure
allocation of unique values.
.PP
\fINote\ 4\fR \ \(em\ The effect of B.7 is that any organization can obtain an
organization code from an appropriate issuing organization, and can then
assign OBJECT IDENTIFIER values for its own purposes, with the assurance
that those
values will not conflict with values assigned by other organizations. By
this means, a manufacturer could, for example, assign an OBJECT IDENTIFIER
to its
own proprietary information formats.
\v'1P'
.RT
.ce 1000
ANNEX\ C
.ce 0
.ce 1000
(to Recommendation X.208)
.sp 9p
.RT
.ce 0
.ce 1000
\fBCCITT assignment of OBJECT IDENTIFIER component values\fR
.sp 1P
.RT
.ce 0
.PP
C.1
Three arcs are specified from the root node. The assignment of
values and identifiers, and the authority for assignment of subsequent
component values, are as follows:
.sp 1P
.RT
.LP
\fBValue\fR
\fBIdentifier\fR \fBAuthority for subsequent\fR \fBassignments\fR
.LP
0
ccitt
CCITT
.LP
1
iso
ISO
.LP
2
joint\(hyiso\(hyccitt
See Annex D
.PP
\fINote\fR \ \(em\ The remainder of this annex concerns itself only with
CCITT assignment of values.
.PP
C.2
The identifiers \*Qccitt\*U, \*Qiso\*U and \*Qjoint\(hyiso\(hyccitt\*U,
assigned
above, may each be used as a \*UNameForm\*U.
.bp
.sp 9p
.RT
.PP
C.3
Four arcs are specified from the node identified by \*Qccitt\*U. The assignment
of values and identifiers is
.LP
\fBValue\fR
\fBIdentifier\fR \fBAuthority for subsequent\fR \fBassignments\fR
.LP
0
recommendation
See \(sc C.4
.LP
1
question
See \(sc C.5
.LP
2
administration
See \(sc C.6
.LP
3
network\(hyoperator
See \(sc C.7
.PP
These identifiers may be used as a \*QNameForm\*U.
.PP
C.4
The arcs below \*Qrecommendation\*U have the value 1 to 26 with
assigned identifiers of a to z. Arcs below these have the numbers of CCITT
Recommendations in the series identified by the letter. Arcs below this are
determined as necessary by the CCITT Recommendation. The identifiers\ a
to\ z may be used as a \*QNameForm\*U.
.sp 9p
.RT
.PP
C.5
The arcs below \*Qquestion\*U have values corresponding to CCITT Study
Groups, qualified by the Study Period. The value is computed by the
formula:
.sp 1P
.ce 1000
study group number + (Period * 32)
.ce 0
.sp 1P
.LP
where \*QPeriod\*U has the value 0 for 1984\(hy1988, 1 for
1988\(hy1992,\ etc., and the multiplier is 32 decimal.
.PP
The arcs below each study group have the values corresponding to the questions
assigned to that study group. Arcs below this are determined as
necessary by the group (e.g. working party or special rapporteur group)
assigned to study the question.
.PP
C.6
The arcs below administration have the values of X.121 DCCs.
Arcs below this are determined as necessary by the Administration of the
country identified by the X.121\ DCC.
.sp 9p
.RT
.PP
C.7
The arcs below \*Qnetwork\(hyoperator\*U have the value of X.121 DNICs.
Arcs below this are determined as necessary by the Administration or RPOA
identified by the DNIC.
.ce 1000
ANNEX\ D
.ce 0
.ce 1000
(to Recommendation X.208)
.sp 9p
.RT
.ce 0
.ce 1000
\fBJoint assignment of OBJECT IDENTIFIER component values\fR
.sp 1P
.RT
.ce 0
.PP
D.1
Three arcs are specified from the root node. The assignment of
values and identifiers, and the authority for assignment of subsequent
component values, are as follows:
.sp 1P
.RT
.LP
\fBValue\fR
\fBIdentifier\fR \fBAuthority for subsequent\fR \fBassignments\fR
.LP
0
ccitt
CCITT
.LP
1
iso
ISO
.LP
2
joint\(hyiso\(hyccitt
See below
.PP
\fINote\fR \ \(em\ The remainder of this annex concerns itself only with
ISO\(hyCCITT assignment of values.
.PP
D.2
The identifiers \*Qccitt\*U, \*Qiso\*U and \*Qjoint\(hyiso\(hyccitt\*U,
assigned
above, may each be used as a \*QNameForm\*U.
.sp 9p
.RT
.PP
D.3
The arcs below \*Qjoint\(hyiso\(hyccitt\*U have values which are assigned
and agreed from time to time by ISO and CCITT to identify areas of joint
ISO\(hyCCITT standardisation activity, in accordance with the \*QProcedures for
assignment of object identifier component values for joint ISO\(hyCCITT
use\*U
.FS
The Registration Authority for assignment of object identifier
component values for joint ISO\(hyCCITT use is the American National Standards
Institute (ANSI), 1430\ Broadway, New\ York, NY\ 10018,\ USA.
.FE
.
.PP
D.4
The arcs beneath each arc identified by the mechanisms of \(sc\ D.3
shall be allocated in accordance with mechanisms established when the arc is
allocated.
.PP
\fINote\fR \ \(em\ It is expected that this will involve delegation of
authority to the joint agreement of CCITT and ISO Rapporteurs for the joint
area of work.
.PP
D.5
Initial ISO Standards and CCITT Recommendations in areas of joint ISO\(hyCCITT
activity require to allocate OBJECT IDENTIFIERS in advance of the
establishment of the procedures of\ D.3, and hence allocate in accordance
with annexes\ B or\ C. Information objects identified in this way by ISO
Standards or CCITT Recommendations shall not have their OBJECT IDENTIFIERS
changed when the procedures of D.3 are established.
\v'1P'
.bp
.sp 9p
.RT
.ce 1000
APPENDIX\ I
.ce 0
.ce 1000
(to Recommendation X.208)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExemples and hints\fR
.sp 1P
.RT
.ce 0
.PP
This appendix contains examples of the use of ASN.1 in the
description of (hypothetical) data structures. It also contains hints, or
guidelines, for the use of the various features of ASN.1.
.sp 1P
.RT
.sp 1P
.LP
I.1
\fIExample of a personnel record\fR
.sp 9p
.RT
.PP
The use of ASN.1 is illustrated by means of a simple, hypothetical personnel
record.
.RT
.sp 1P
.LP
I.1.1
\fIInformal description of personnel record\fR
.sp 9p
.RT
.PP
The structure of the personnel record and its value for a
particular individual are shown below.
.RT
.LP
Name:
John P Smith
.LP
Title:
Director
.LP
Employee Number:
51
.LP
Date of Hire:
17 September 1971
.LP
Name of Spouse:
Mary T Smith
.LP
Number of Children:
2
.LP
Child Information
.LP
Name:
Ralph T Smith
.LP
Date of Birth
11 November 1957
.LP
Child Information
.LP
Name:
Susan B Jones
.LP
Date of Birth
17 July 1959
.sp 1P
.LP
I.1.2
\fIASN.1 description of the record structure\fR
.sp 9p
.RT
.PP
The structure of every personnel record is formally described below using
the standard notation for data types.
.RT
.LP
PersonnelRecord ::= [APPLICATION 0] IMPLICIT SET
.LP
{
Name,
.LP
\ title
[0] VisibleString,
.LP
\ number
EmployeeNumber,
.LP
\ dateOfHire
[1] Date,
.LP
\ nameOfSpouse
[2] Name,
.LP
\ children
[3] IMPLICIT
.LP
SEQUENCE OF
.LP
ChildInformation
.LP
DEFAULT\ {\|}\ }
.LP
ChildInformation ::= SET
.LP
\ \ {
Name,
.LP
\ \ \ dateOfBirth
[0] Date}
.LP
Name ::= [APPLICATION 1] IMPLICIT SEQUENCE
.LP
{givenName
VisibleString,
.LP
\ initial
VisibleString,
.LP
\ familyName
VisibleString}
.LP
EmployeeNumber ::= [APPLICATION 2] IMPLICIT INTEGER
.LP
Date ::= [APPLICATION 3] IMPLICIT VisibleString\(hy\(hy\ YYYYMMDD
.bp
.PP
This example illustrates an aspect of the parsing of the ASN.1
syntax. The sintactic construct \*QDEFAULT\*U can only be applied to an
element of a \*QSEQUENCE\*U or a \*QSET\*U, it cannot be applied to an
element of a \*QSEQUENCE\ OF\*U. Thus the \*QDEFAULT\ {\|}\*U in \*QPersonnelRecord\*U
applies to \*Qchildren\*U, not to
\*QChildInformation\*U.
.sp 1P
.LP
I.1.3
\fIASN.1 description of a record value\fR
.sp 9p
.RT
.PP
The value of John Smith's personnel record is formally described
below using the standard notation for data values.
.RT
.LP
{
{givenName \*QJohn\*U,initial \*QP\*U,familyName \*QSmith\*U}
.LP
\ title
\*QDirector\*U
.LP
\ number
51
.LP
\ dataOfHire
\*Q19710917\*U
.LP
\ nameOfSpouse
{givenName \*QMary\*U,initial \*QT\*U,familyName \*QSmith\*U}
.LP
\ children
.LP
\ \ {{{\ givenName \*QRalph\*U,initial \*QT\*U,familyName \*QSmith\*U}
.LP
\ \ \ \ \ dateOfBirth \*Q19571111\*U}
.LP
\ \ \ \ \ {{givenName \*USusan\*U,initial \*QB\*U,familyName \*QJones\*U}
.LP
\ \ \ \ \ dateOfBirth \*Q19590717\*U}}}
.sp 1P
.LP
I.2
\fIGuidelines for use of the notation\fR
.sp 9p
.RT
.PP
The data types and formal notation defined by this Recommendation are flexible,
allowing a wide range of protocols to be designed using them.
This flexibility, however, can sometimes lead to confusion, especially
when the notation is approached for the first time. This Annex attempts
to minimise
confusion by giving guidelines for, and examples of, the use of the notation.
For each of the built\(hyin data types, one or more usage guidelines are
offered. The character string types (for example, VisibleString) and the
types defines in section three are not dealt with here.
.RT
.sp 2P
.LP
I.2.1
\fIBoolean\fR
.sp 1P
.RT
.PP
I.2.1.1
Use a Boolean type to model the values of a logical (that
is, two\(hystate) variable, for example, the answer to a yes\(hyor\(hyno
question.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Employed ::= BOOLEAN
.PP
I.2.1.2
When assigning a reference name to a Boolean type, choose one
that describes the \fBtrue\fR state.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Married ::= BOOLEAN
.LP
not
.LP
MaritalStatus ::= BOOLEAN
.PP
See also \(sc I.2.3.2
.sp 2P
.LP
I.2.2
\fIInteger\fR
.sp 1P
.RT
.PP
I.2.2.1
Use an integer type to model the values (for all practical
purposes, unlimited in magnitude) of a cardinal or integer variable.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
CheckingAccountBalance ::= INTEGER
.LP
\ \(hy\(hy\ in cents; negative means overdrawn
.PP
I.2.2.2
Define the minimum and maximum allowed values of an integer type as distinguished
values.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
DayOfTheMonth ::= INTEGER {first(1),last(31)}
.bp
.sp 2P
.LP
I.2.3
\fIEnumerated\fR
.sp 1P
.RT
.PP
I.2.3.1
Use an enumerated type with distinguished values to model the
values of a variable with three or more states. Assign values starting with
zero if their only constraint is distinctness.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
DayOfTheWeek ::= ENUMERATED
.LP
\ {sunday(0),monday(1),tuesday(2),wednesday(3),thursday(4),friday(5),saturday(6)}
.PP
I.2.3.2
Use an enumerated type to model the values of a variable that
has just two states now but that may have additional states in a future
version of the protocol.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
MaritalStatus ::= ENUMERATED {single(0),married(1)}
.LP
in anticipation of
.LP
MaritalStatus ::= ENUMERATED {single(0),married(1),widowed(2)}
.sp 2P
.LP
I.2.4
\fIReal\fR
.sp 1P
.RT
.PP
I.2.4.1
Use a real type to model an approximate number.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
AngleInRadians ::= REAL
.LP
pi REAL ::= {3141592653589793238462643383279, 10, \(em30}
.sp 2P
.LP
I.2.5
\fIBit string\fR
.sp 1P
.RT
.PP
I.2.5.1
Use a bit string type to model binary data whose format and
length are unspecified, or specified elsewhere, and whose length in bits
is not necessarily a multiple of eight.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
G3FacsimilePage ::= BIT STRING
.LP
\ \(hy\(hy\ a sequence of bits conforming to CCITT
.LP
\ \(hy\(hy\ Recommendation T.4.
.PP
I.2.5.2
Define the first and last meaningful bits of a fixed\(hylength bit string
as distinguished bits.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Nibble ::= BIT STRING {first(0),last(3)}
.PP
I.2.5.3
Use a bit string type to model the values of a \fBbit map\fR , an
ordered collection of logical variables indicating whether a particular
condition holds for each of a correspondingly ordered collection of objects.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
SunnyDaysOfTheMonth ::= BIT STRING {first(1),last(31)}
.LP
\ \(hy\(hy\ Day i was sunny if and only if bit i is one
.PP
I.2.5.4
Use a bit string type with distinguished values to model the
values of a collection of related logical variables.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
PersonalStatus ::= BIT STRING
.LP
\ {married(0),employed(1),veteran(2),collegeGraduate(3)}
.sp 2P
.LP
I.2.6
\fIOctet string\fR
.sp 1P
.RT
.PP
I.2.6.1
Use an octet string type to model binary data whose format and length are
unspecified, or specified elsewhere, and whose length in bits is a multiple
of eight.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
G4FacsimileImage ::= OCTET STRING
.LP
\ \(hy\(hy\ a sequence of octets conforming to
.LP
\ \(hy\(hy\ CCITT Recommendations T.5 and T.6
.bp
.PP
I.2.6.2
Use a character string type in preference to an octet string
type, where an appropriate one is available.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Surname ::= PrintableString
.PP
I.2.6.3
Use an octet string type to model any string of information
which cannot be modelled using one of the character string types. Be sure to
specify the repertoire of characters and their coding into octets.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
PackedBCDString ::= OCTET STRING
.LP
\ \(hy\(hy\ the digits 0 through 9, two digits per octet,
.LP
\ \(hy\(hy\ each digit encoded as 0000 to 1001,
.LP
\ \(hy\(hy\ 1111\d2\uused for padding.
.sp 1P
.LP
I.2.7
\fINull\fR
.sp 9p
.RT
.PP
Use a null type to indicate the effective absence of an element of a sequence.
.RT
.LP
\fIExample:\fR
.LP
PatientIdentifier ::= SEQUENCE
.LP
\ {name
VisibleString,
.LP
\ roomNumber
CHOICE
.LP
\ \ \ \ \ {INTEGER,
.LP
\ \ \ \ \ NULL\ \(hy\(hy\ if an out\(hypatient\ \(hy\(hy}}
.PP
\fINote\fR \ \(em\ The use of \*QOPTIONAL\*U provides an equivalent facility.
.sp 2P
.LP
I.2.8
\fISequence and sequence\(hyof\fR
.sp 1P
.RT
.PP
I.2.8.1
Use a sequence\(hyof type to model a collection of variables whose types
are the same, whose number is large or unpredictable, and whose order is
significant.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
NamesOfMemberNations ::= SEQUENCE OF VisibleString
.LP
\ \(hy\(hy\ in the order in which they joined
.PP
I.2.8.2
Use a sequence type to model a collection of variables whose
types are the same, whose number is known and modest, and whose order is
significant, provided that the makeup of the collection is unlikely to
change from one version of the protocol to the next.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
NamesOfOfficers ::= SEQUENCE
.LP
{president
VisibleString,
.LP
\ vicePresident
VisibleString,
.LP
\ secretary
VisibleString}
.PP
I.2.8.3
Use a sequence type to model a collection of variables whose
types differ, whose number is known and modest, and whose order is significant,
provided that the makeup of the collection is unlikely to change from one
version of the protocol to the next.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Credentials ::= SEQUENCE
.LP
\ {userName
VisibleString,
.LP
\ password
VisibleString,
.LP
\ accountNumber
INTEGER}
.bp
.PP
I.2.8.4
If the elements of a sequence type are fixed in number but of
several types, a reference name should be assigned to every element whose
purpose is not fully evident from its type.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
File ::= SEQUENCE
.LP
\ {
ContentType,
.LP
\ other
FileAttributes,
.LP
\ content
ANY}
.PP
See also \(sc I.2.5.3, \(sc I.2.5.4, and \(sc I.2.7.
.sp 2P
.LP
I.2.9
\fISet\fR
.sp 1P
.RT
.PP
I.2.9.1
Use a set type to model a collection of variables whose number is known
and modest and whose order is insignificant. Identify each variable by
context\(hyspecifically tagging it.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
UserName ::= SET
.LP
\ {personalName
[0] IMPLICIT VisibleString,
.LP
\ organisationName
[1] IMPLICIT VisibleString,
.LP
\ countryName
[2] IMPLICIT VisibleString}
.PP
I.2.9.2
Use a set type with \*QOPTIONAL\*U to model a collection of
variables that is a (proper or improper) subset of another collection of
variables whose number is known and reasonably small and whose order is
insignificant. Identify each variable by context\(hyspecifically tagging it.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
UserName ::= SET
.LP
\ {personalName
[0] IMPLICIT VisibleString,
.LP
\ organisationName
[1] IMPLICIT VisibleString OPTIONAL
.LP
\ \ \(hy\(hy\ defaults to that of the local organisation\ \(hy\(hy,
.LP
\ countryName
[2] IMPLICIT VisibleString OPTIONAL
.LP
\ \ \(hy\(hy\ defaults to that of the local country\ \(hy\(hy}
.PP
I.2.9.3
Use a set type to model a collection of variables whose makeup is likely
to change from one version of the protocol to the next. Identify each variable
by context\(hyspecifically tagging it.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
UserName ::= SET
.LP
\ {personalName
[0] IMPLICIT VisibleString,
.LP
\ organisationName
[1] IMPLICIT VisibleString OPTIONAL
.LP
\ \ \(hy\(hy\ defaults to that of the local organisation\ \(hy\(hy,
.LP
\ countryName
[2] IMPLICIT VisibleString OPTIONAL
.LP
\ \ \(hy\(hy\ defaults to that of the local country
.LP
\ \ \(hy\(hy\ other optional attributes are for further study\ \(hy\(hy}
.PP
I.2.9.4
If the members of a set type are fixed in number, a reference
name should be assigned to every member whose purpose is not fully evident
from its type.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
FileAttributes ::= SET
.LP
\ {owner
[0] IMPLICIT UserName,
.LP
\ sizeOfContentInOctets
[1] IMPLICIT INTEGER,
.LP
[2] IMPLICIT AccessControls,
.LP
\ .\|.\|.}
.bp
.PP
I.2.9.5
Use a set type to model a collection of variables whose types
are the same and whose order is insignificant.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Keywords ::= SET OF VisibleString\ \(hy\(hy\ in arbitrary order
.PP
See also \(sc I.2.5.4 and \(sc I.2.10.3.
.sp 2P
.LP
I.2.10\ \ \fITagged\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.10.1\ \ Use a universal tagged type to define \(em\ in this Recommendation
only\ \(em a generally useful, application independent data type that must be
distinguishable (by means of its representation) from all other data types.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
EncryptionKey ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
.LP
\(hy\(hy\ seven octets
.sp 1P
.LP
I.2.10.2\ \ Use an application\(hywide tagged type to define a data type that
finds wide, scattered use within a particular presentation context and that
must be dintinguisable (by means of its representation) from all other data
types used in the presentation context.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
FileName ::= [APPLICATION 8] IMPLICIT SEQUENCE
.LP
\ {directoryName
VisibleString,
.LP
\ directoryRelativeFileName
VisibleString}
.sp 1P
.LP
I.2.10.3\ \ Use context\(hyspecific tagged types to distinguish the members
of a set. Assign numeric tags starting with zero if their only constraint
is
distinctness.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
CustomerRecord ::= SET
.LP
\ {name
[0] IMPLICIT VisibleString,
.LP
\ mailingAddress
[1] IMPLICIT VisibleString,
.LP
\ accountNumber
[2] IMPLICIT INTEGER,
.LP
\ balanceDue
[3] IMPLICIT INTEGER\ \(hy\(hy\ in cents\ \(hy\(hy}
.sp 1P
.LP
I.2.10.4\ \ Where a particular set member has been application\(hywide
tagged, a further context\(hyspecific tag need not be used, unless it is
(or may be in the future) needed for distinctness. Where the set member
has been universally
tagged, a further context\(hyspecific tag should be used.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
ProductRecord ::= SET
.LP
\ {
UniformCode,
.LP
\ description
[0] IMPLICIT VisibleString,
.LP
\ inventoryNo
[1] IMPLICIT INTEGER,
.LP
\ inventoryLevel
[2] IMPLICIT INTEGER}
.LP
UniformCode ::= [APPLICATION 13] IMPLICIT INTEGER
.bp
.sp 1P
.LP
I.2.10.5\ \ Use context\(hyspecific tagged types to distinguish the
alternatives of a CHOICE. Assign numeric tags starting with zero if their
only constraint is distinctness.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
CustomerAttribute ::= CHOICE
.LP
\ {name
[0] IMPLICIT VisibleString,
.LP
\ mailingAddress
[1] IMPLICIT VisibleString,
.LP
\ accountNumber
[2] IMPLICIT INTEGER,
.LP
\ balanceDue
[3] IMPLICIT INTEGER\ \(hy\(hy\ in cents\ \(hy\(hy}
.sp 1P
.LP
I.2.10.6\ \ Where a particular CHOICE alternative has been defined using an
application\(hywide tagged type, a further context\(hyspecific tag need
not be used, unless it is (or maybe in the future) needed for distinctness.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
ProductDesignator ::= CHOICE
.LP
\ {
UniformCode,
.LP
\ description
[0] IMPLICIT VisibleString,
.LP
\ inventoryNo
[1] IMPLICIT INTEGER}
.LP
UniformCode ::= [APPLICATION 13] IMPLICIT INTEGER
.sp 1P
.LP
I.2.10.7\ \ Where a particular CHOICE alternative has been universally
tagged, a further context\(hyspecific tag should be used, unless the provision
of more than one universal type is the purpose of the choice.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
CustomerIdentifier ::= CHOICE
.LP
\ {name
VisibleString,
.LP
\ number
INTEGER}
.sp 1P
.LP
I.2.10.8\ \ Use a private\(hyuse tagged type to define a data type that finds
use within a particular organisation or country and that must be
distinguishable (by means of its representation) from all other data types
used by that organisation or country.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
AcmeBadgeNumber ::= [PRIVATE 2] IMPLICIT INTEGER
.sp 1P
.LP
I.2.10.9\ \ These guidelines use implicit tagging in the examples whenever
it is legal to do so. This may, depending on the encoding rules, result
in a
compact representation, which is highly desirable in some applications. In
other applications, compactness may be less important than, for example, the
ability to carry out strong type\(hychecking. In the latter case, explicit
tagging can be used.
.sp 9p
.RT
.PP
See also \(sc I.2.9.1, \(sc I.2.9.2, \(sc I.2.11.1 and \(sc I.2.11.2.
.sp 2P
.LP
I.2.11\ \ \fIChoice\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.11.1\ \ Use a CHOICE to model a variable that is selected from a
collection of variables whose number is known and modest. Identify each
candidate variable by context\(hyspecifically tagging it.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
FileIdentifier ::= CHOICE
.LP
\ {relativeName
[0] IMPLICIT VisibleString,
.LP
\ \ \ \(hy\(hy\ name of file (for example, \*QMarchProgressReport\*U)
.LP
\ absoluteName
[1] IMPLICIT VisibleString,
.LP
\ \ \ \(hy\(hy\ name of file and containing directory
.LP
\ \ \ \(hy\(hy\ (for example, \*Q<Williams>MarchProgressReport\*U)
.LP
\ serialNumber
[2] IMPLICIT INTEGER
.LP
\ \ \ \(hy\(hy\ system\(hyassigned identifier for file\ \(hy\(hy}
.bp
.sp 1P
.LP
I.2.11.2\ \ Use a CHOICE to model a variable that is selected from a
collection of variables whose makeup is likely to change from one version of
the protocol to the next. Identify each candidate variable by
context\(hyspecifically tagging it.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
FileIdentifier ::= CHOICE
.LP
\ {relativeName
[0] IMPLICIT VisibleString,
.LP
\ \ \ \(hy\(hy\ name of file (for example, \*QMarchProgressReport\*U)
.LP
\ absoluteName
[1] IMPLICIT VisibleString,
.LP
\ \ \ \(hy\(hy\ name of file and containing directory
.LP
\ \ \ \(hy\(hy\ (for example, \*Q<Williams>MarchProgressReport\*U)
.LP
\ \(hy\(hy\ other forms of file identifiers are for further study\ \(hy\(hy}
.sp 1P
.LP
I.2.11.3\ \ A reference name should be assigned to each alternative whose
purpose is not fully evident from its type.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
FileIdentifier ::= CHOICE
.LP
\ {relativeName
[0] IMPLICIT VisibleString,
.LP
\ \ \ \(hy\(hy\ name of file (for example, \*QMarchProgressReport\*U)
.LP
\ absoluteName
[1] IMPLICIT VisibleString,
.LP
\ \ \ \(hy\(hy\ names of file and containing directory
.LP
\ \ \ \(hy\(hy\ (for example, \*Q<Williams>MarchProgressReport\*U)
.LP
[2] IMPLICIT SerialNumber
.LP
\ \ \ \(hy\(hy\ system\(hyassigned identifier for file\ \(hy\(hy}
.sp 1P
.LP
I.2.11.4\ \ Where implicit tagging is the norm in a particular application
of this Recommendation, use a CHOICE of only one type where the possibility
is
envisaged or more than one type being permitted in the future. This precludes
the possibility of implicit tagging taking place, and thus aids transition.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Greeting ::= [APPLICATION 12] CHOICE
.LP
{VisibleString}
.LP
in anticipation of
.LP
Greeting ::= [APPLICATION 12] CHOICE
.LP
{VisibleString,
.LP
Voice}
.sp 2P
.LP
I.2.12\ \ \fISelection type\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.12.1\ \ Use a selection type to model a variable whose type is that of
some particular alternatives of a previously defined CHOICE.
.sp 9p
.RT
.sp 1P
.LP
I.2.12.2\ \ Consider the definition:
.sp 9p
.RT
.LP
FileAttribute ::= CHOICE
.LP
{date\(hylast\(hyused
INTEGER,
.LP
\ file\(hyname
VisibleString}
.LP
then the following definition is possible:
.LP
CurrentAttributes ::= SEQUENCE
.LP
{date\(hylast\(hyused
<FileAttribute,
.LP
\ file\(hyname
<FileAttribute}
.LP
with a possible value notation of
.LP
{date\(hylast\(hyused 27
.LP
\ file\(hyname \*QPROGRAM\*U}
.bp
.PP
The following definition is also possible:
.LP
AttributeList ::= SEQUENCE
.LP
{first\(hyattribute date\(hylast\(hyused
<FileAttribute,
.LP
\ second\(hyattribute file\(hyname
<FileAttribute}
.LP
with a possible value notation of
.LP
{first\(hyattribute 27,
.LP
\ second\(hyattribute \*QPROGRAM\*U}
.sp 2P
.LP
I.2.13\ \ \fIAny\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.13.1\ \ Use an any type to model a variable whose type is unspecified,
or specified elsewhere using ASN.1.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
MessageContents ::= ANY
.LP
\ \(hy\(hy\ a data element whose type is specified
.LP
\ \(hy\(hy\ outside this Recommendation using the ASN.1 notation.
.sp 2P
.LP
I.2.14\ \ \fIExternal\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.14.1\ \ Use an external type to model a variable whose type is
unspecified, or specified elsewhere with no restriction on the notation
used to specify the type.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
FileContents ::= EXTERNAL
.LP
DocumentList ::= SEQUENCE OF EXTERNAL
.sp 1P
.LP
I.3
\fIAn example of the use of the macro notation\fR
.sp 9p
.RT
.PP
Suppose it is desired to have a notation for type definition of the form
.RT
.LP
PAIR TYPEX = .\|.\|.\|. TYPEY = .\|.\|.\|.
.LP
with a corresponding value notation allowing
.LP
(X = \(hy\(hy\(hy\(hy, Y = \(hy\(hy\(hy\(hy)
.PP
The .\|.\|.\|. and the \(hy\(hy\(hy\(hy refer to any ASN.1 type and corresponding
value respectively.
.PP
This macro type notation could be used to define types and values as follows:
.RT
.LP
T1 ::= PAIR
.LP
TYPEX = INTEGER
.LP
TYPEY = BOOLEAN
.LP
T2 ::= PAIR
.LP
TYPEX = VisibleString
.LP
TYPEY = T1
.PP
Then a value of type T1 might be:
.LP
(X = 3, Y = TRUE)
.LP
and a value of type T2 might be:
.LP
(X = \*QName\*U, Y = (X = 4, Y = FALSE))
.bp
.PP
The following macro definition could be used to establish this new notation,
as an extension of the basic ASN.1:
.LP
PAIR
.LP
MACRO ::= BEGIN
.LP
TYPE NOTATION ::=
.LP
\*QTYPEX\*U
.LP
\*Q=\*U
.LP
type (Local\(hytype\(hy1)
.LP
\ \(hy\(hy\ Expects any ASN.1 type and assigns it
.LP
\ \(hy\(hy\ to the variable Local\(hytype\(hy1;
.LP
\*QTYPEY\*U
.LP
\*Q=\*U
.LP
type (Local\(hytype\(hy2)
.LP
\ \(hy\(hy\ Expects a second ASN.1 type and assigns
.LP
\ \(hy\(hy\ it to the variable Local\(hytype\(hy2;
.LP
VALUE NOTATION ::=
.LP
\*Q(\*U
.LP
\*QX\*U
.LP
\*Q=\*U
.LP
value (Local\(hyvalue\(hy1 Local\(hytype\(hy1)
.LP
\ \(hy\(hy\ Expects a value for the type in
.LP
\ \(hy\(hy\ Local\(hytype\(hy1, and assigns it
.LP
\ \(hy\(hy\ to the variable Local\(hyvalue\(hy1;
.LP
\*Q,\*U
.LP
\*QY\*U
.LP
\*Q=\*U
.LP
value (Local\(hyvalue\(hy2 Local\(hytype\(hy2)
.LP
\ \(hy\(hy\ Expects a value for the type in
.LP
\ \(hy\(hy\ Local\(hytype\(hy2 and assigns it
.LP
\ \(hy\(hy\ to the variable Local\(hyvalue\(hy2;
.LP
<VALUE SEQUENCE {Local\(hytype\(hy1, Local\(hytype\(hy2}
.LP
\ ::= {Local\(hyvalue\(hy1, Local\(hyvalue\(hy2}>
.LP
\(hy\(hy\ This \*Qembedded definition\*U returns
.LP
\(hy\(hy\ the final value as the value
.LP
\(hy\(hy\ of a sequence of the two types.
.LP
\*Q)\*U
.LP
END
.PP
In this example, the basic ASN.1 type of the returned value is
independent of the actual instance of the value notation, but does depend on
the instance of the type notation that is used. In other cases, it may be
fully determined by the macro definition, or it may depend on the instance
of the value notation that is used. Note, however, that in all cases it
is the
\*QVALUE NOTATION\*U production that needs to be examined in order to determine
the type of the returned value. The \*QTYPE NOTATION\*U production simply
defines the syntax for type definition, and establishes the initial value
of local
variables for use when analysing an instance of the value notation.
.sp 2P
.LP
I.4
\fIUse in identifying abstract syntaxes\fR
.sp 1P
.RT
.PP
I.4.1
Use of the presentation service (Recommendation X.216) requires
the specification of values called \fBpresentation data values\fR and the
grouping of those presentation data values into sets which are called \fBabstract\fR
\fBsyntaxes\fR . Each of these sets is given an \fBabstract syntax name\fR
of ASN.1 type object identifier.
.sp 9p
.RT
.PP
I.4.2
ASN.1 can be used as a general tool in the specification of
presentation data values and their grouping into named abstract syntaxes.
.PP
I.4.3
In the simplest such use, there is a single ASN.1 type such that every
presentation data value in the named abstract syntax is a value of that
ASN.1 type. This type will normally be a choice type, and every presentation
data value will be an alternative type from this choice type. In this case
it is recommended that the ASN.1 module notation be used to contain this
choice
type as the first defined type, followed by the definition of those
(non\(hyuniversal) types referenced directly or indirectly by this choice type.
.PP
\fINote\fR \ \(em\ This is not intended to exclude references to types
defined in other modules.
.bp
.PP
I.4.4
The following is an example of text which might appear in an
application standard. The end of the example is identified by the phrase
\*QEND OF EXAMPLE\*U in order to avoid confusion.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
ISOxxxx\(hyyyyy DEFINITIONS ::=
.LP
BEGIN
.LP
PDU ::= CHOICE
.LP
\ \ {connect\(hypdu\ \ .\|.\|.,
.LP
\ \ \ data\(hypdu\ \ CHOICE
.LP
\ \ \ \ \ \ \ {\ .\|.\|.,
.LP
\ \ \ \ \ \ .\|.\|.}\ \ ,
.LP
\ \ .\|.\|.\ \ \ \ \ }
.LP
.\|.\|.
.LP
END
.LP
This International Standard assigns the ASN.1 object identifier
value
.LP
{iso standard xxxx abstract\(hysyntax (1)}
.LP
as an abstract syntax name for the set of presentation data
values, each of which is a value of the ASN.1 type
\*QISOxxxx\(hyyyyy.PDU\*U.
.LP
The corresponding ASN.1 object descriptor value shall be
.LP
\*Q..............................\*U
.LP
The ASN.1 object identifier and object descriptor values
.LP
{joint\(hyiso\(hyccitt asn1 (1) basic\(hyencoding (1)}
.LP
and
.LP
\*QBasic Encoding of a single ASN.1 type\*U
.LP
(assigned to an information object in Recommendation X.209) can be
used as a transfer syntax name with this abstract syntax name.
.LP
END OF EXAMPLE
.PP
I.4.5
The standard may additionally make support of the transfer syntax obtained
by applying
.sp 9p
.RT
.LP
{joint\(hyiso\(hyccitt asn1 (1) basic\(hyencoding (1)}
.LP
mandatory for this abstract syntax
.sp 2P
.LP
I.5
\fISubtypes\fR
.sp 1P
.RT
.PP
I.5.1
Use subtypes to limit the values of an existing type which are to be permitted
in a particular situation.
.sp 9p
.RT
.LP
\fIExamples:\fR
.LP
AtomicNumber ::=INTEGER (1..104)
.LP
TouchToneString ::= IA5String (FROM
.LP
(\*Q0\*U|\*Q1\*U|\*Q2\*U|\*Q3\*U|\*Q4\*U|\*Q5\*U|\*Q6\*U|
.LP
\*Q7\*U|\*Q8\*U|\*Q9\*U|\*Q*\*U|\*Q##\*U)|
.LP
SIZE (1..63))
.LP
ParameterList ::= SET SIZE (0..63) OF Parameter
.LP
SmallPrime ::= INTEGER (2|3|5|7|11|13|17|19|23|29)
.bp
.PP
I.5.2
Where two or more related types have significant commonality,
consider explicitly defining their common parent as a type and use subtyping
for the individual types. This approach makes clear the relationship and the
commonality, and encourages (though does not force) this to continue as the
types evolve. It thus facilitates the use of common implementation approaches
to the handling of values of these types.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Envelope ::= SET {typeA TypeA,
.LP
\ typeB TypeB OPTIONAL,
.LP
\ typeC TypeC OPTIONAL}
.LP
\ \(hy\(hy\ the common parent
.LP
ABEnvelope ::= Envelope (WITH COMPONENTS
.LP
\ {.\|.\|.,
.LP
\ typeB PRESENT, typeC ABSENT})
.LP
\ \(hy\(hy\ where typeB must always
.LP
\ \(hy\(hy\ appear and typeC must not
.LP
ACEnvelope ::= Envelope (WITH COMPONENTS
.LP
\ {.\|.\|.,
.LP
\ typeB ABSENT, typeC PRESENT})
.LP
\ \(hy\(hy\ where typeC must always
.LP
\ \(hy\(hy\ appear and typeB must not
.PP
The latter definitions could alternatively be expressed as
.LP
ABEnvelope ::= Envelope (WITH COMPONENTS {typeA,typeB})
.LP
ACEnvelope ::= Envelope (WITH COMPONENTS {typeA,typeC})
.PP
The choice between the alternatives would be made upon such
factors as the number of components in the parent type, and the number
of those which are optional, the extent of the difference between the individual
types, and the likely evolution strategy.
.PP
I.5.3
Use subtyping to partially define a value, for example, a protocol data
unit to be tested for in a conformance test, where the test is concerned
only with some components of the PDU.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Given:
.LP
PDU ::= SET
.LP
{alpha
[0]
INTEGER,
.LP
\ beta
[1]
IA5String OPTIONAL,
.LP
\ gamma
[2]
SEQUENCE OF Parameter,
.LP
\ delta
[3]
BOOLEAN}
.LP
then in composing a test which requires the Boolean to be false
and the integer to be negative, write:
.LP
TestPDU ::= PDU (WITH COMPONENTS
.LP
{\ .\|.\|.,
.LP
\ delta (FALSE),
.LP
\ alpha (MIN.\|.\|.<0)})
.LP
and if, further, the IA5String, beta, is to be present and either
5 or 12 characters in length, write:
.LP
FurtherTestPDU ::= TestPDU (WITH COMPONENTS
.LP
{\ .\|.\|.,
.LP
\ beta (SIZE (5|12)) PRESENT})
.bp
.PP
I.5.4
If a general\(hypurpose datatype has been defined as a SEQUENCE OF, use
subtyping to define a restricted subtype of the general type:
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Text\(hyblock ::= SEQUENCE OF VisibleString
.LP
Address ::= Text\(hyblock
.LP
(SIZE (1..6) |
.LP
WITH COMPONENT (SIZE(1..32)))
.PP
I.5.5
Use contained subtypes to form new subtypes from existing
subtypes:
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
Months ::= ENUMERATED {
.LP
january (1),
.LP
february (2),
.LP
march (3),
.LP
april (4),
.LP
may (5),
.LP
june (6),
.LP
july (7),
.LP
august (8),
.LP
september (9),
.LP
october (10),
.LP
november (11),
.LP
december (12)}
.LP
First\(hyquarter ::= Months (
.LP
january\ |
.LP
february\ |
.LP
march)
.LP
Second\(hyquarter ::= Months (
.LP
april\ |
.LP
may\ |
.LP
june)
.LP
Third\(hyquarter ::= Months (
.LP
july\ |
.LP
august\ |
.LP
september)
.LP
Fourth\(hyquarter ::= Months (
.LP
october\ |
.LP
november\ |
.LP
december)
.LP
First\(hyhalf ::= Months (
.LP
INCLUDES First\(hyquarter\ |
.LP
INCLUDES Second\(hyquarter)
.LP
Second\(hyhalf ::= Months (
.LP
INCLUDES Third\(hyquarter\ |
.LP
INCLUDES Fourth\(hyquarter\ )
\v'1P'
.bp
.ce 1000
APPENDIX\ II
.ce 0
.ce 1000
(to Recommendation X.208)
.sp 9p
.RT
.ce 0
.ce 1000
\fBSummary of the ASN.1 notation\fR
.sp 1P
.RT
.ce 0
.PP
The following items are defined in clause 8:
.sp 1P
.RT
.LP
typereference
INTEGER
BEGIN
.LP
identifier
BIT
END
.LP
valuereference
STRING
DEFINITIONS
.LP
modulereference
OCTET
EXPLICIT
.LP
comment
NULL
ENUMERATED
.LP
empty
SEQUENCE
EXPORTS
.LP
number
OF
IMPORTS
.LP
bstring
SET
.LP
hstring
IMPLICIT
REAL
.LP
cstring
CHOICE
INCLUDES
.LP
\*Q::=\*U
ANY
MIN
.LP
{
EXTERNAL
MAX
.LP
}
OBJECT
SIZE
.LP
<
IDENTIFIER
FROM
.LP
,
OPTIONAL
WITH
.LP
.
DEFAULT
COMPONENT
.LP
(
COMPONENTS
PRESENT
.LP
)
UNIVERSAL
ABSENT
.LP
[
APPLICATION
DEFINED
.LP
]
PRIVATE
BY
.LP
\(hy
TRUE
PLUS\(hyINFINITY
.LP
BOOLEAN
FALSE
MINUS\(hyINFINITY
.PP
The following productions are used in this Recommendation, with
the above items as terminal symbols:
.LP
ModuleDefinition ::=
.LP
ModuleIdentifier
.LP
DEFINITIONS
.LP
TagDefault
.LP
\*Q::=\*U
.LP
BEGIN
.LP
ModuleBody
.LP
END
.LP
TagDefault ::=
.LP
EXPLICIT TAGS\ |
.LP
IMPLICIT TAGS\ |
.LP
empty
.LP
ModuleIdentifier ::=
.LP
modulereference
.LP
AssignedIdentifier
.LP
AssignedIdentifier ::=
.LP
ObjectIdentifier Value\ |
.LP
empty
.LP
ModuleBody ::=
.LP
Exports Imports AssignmentList\ |
.LP
empty
.LP
Exports ::=
.LP
EXPORTS SymbolsExported;\ |
.LP
empty
.LP
SymbolsExported ::=
.LP
SymbolList\ |
.LP
empty
.bp
.LP
Imports ::=
.LP
IMPORTS SymbolsImported;\ |
.LP
empty
.LP
SymbolsImported ::=
.LP
SymbolsFromModuleList\ |
.LP
empty
.LP
SymbolsFromModuleList ::=
.LP
SymbolsFromModule SymbolsFromModuleList\ |
.LP
SymbolsFromModule
.LP
SymbolsFromModule ::=
.LP
SymbolList FROM ModuleIdentifier
.LP
SymbolList ::= Symbol, SymbolList\ |\ Symbol
.LP
Symbol ::= typereference\ |\ valuereference
.LP
AssignmentList ::=
.LP
Assignment AssignmentList\ |
.LP
Assignment
.LP
Assignment ::= Typeassignment\ |\ Valueassignment
.LP
Externaltypereference ::=
.LP
modulereference
.LP
.
.LP
typereference
.LP
Externalvaluereference ::=
.LP
modulereference
.LP
.
.LP
valuereference
.LP
DefinedType ::= Externaltypereference\ |\ typereference
.LP
DefinedValue ::= Externalvaluereference\ |\ valuereference
.LP
Typeassignment ::=
.LP
typereference
.LP
\*Q::=\*U
.LP
Type
.LP
Valueassignment ::=
.LP
valuereference
.LP
Type
.LP
\*Q::=\*U
.LP
Value
.LP
Type ::= BuiltinType\ |\ DefinedType\ |\ Subtype
.LP
BuiltinType ::=
.LP
BooleanType
|
.LP
IntegerType
|
.LP
BitStringType
|
.LP
OctetStringType
|
.LP
NullType
|
.LP
SequenceType
|
.LP
SequenceOfType
|
.LP
SetType
|
.LP
SetOfType
|
.LP
ChoiceType
|
.LP
SelectionType
|
.LP
TaggedType
|
.LP
AnyType
|
.LP
ObjectIdentifierType
|
.LP
CharacterStringType
|
.LP
UsefulType
|
.LP
EnumeratedType
|
.LP
RealType
|
.bp
.LP
NamedType ::= identifier Type\ |\ Type\ |\ SelectionType
.LP
Value ::= BuiltinValue\ |\ DefinedValue
.LP
BuiltinValue ::=
.LP
BooleanValue
|
.LP
IntegerValue
|
.LP
BitStringValue
|
.LP
OctetStringValue
|
.LP
NullValue
|
.LP
SequenceValue
|
.LP
SequenceOfValue
|
.LP
SetValue
|
.LP
SetOfValue
|
.LP
ChoiceValue
|
.LP
SelectionValue
|
.LP
TaggedValue
|
.LP
AnyValue
|
.LP
ObjectIdentifierValue
|
.LP
CharacterStringValue
|
.LP
EnumeratedValue
|
.LP
RealValue
|
.LP
NamedValue ::= identifier Value\ |\ Value
.LP
BooleanType ::= BOOLEAN
.LP
BooleanValue ::= TRUE\ |\ FALSE
.LP
IntegerType ::= INTEGER\ |\ INTEGER {NamedNumberList}
.LP
NamedNumberList ::=
.LP
NamedNumber\ |
.LP
NamedNumberList,NamedNumber
.LP
NamedNumber ::=
.LP
identifier(SignedNumber)\ |
.LP
identifier(DefinedValue)
.LP
SignedNumber ::= number\ |\ \(hynumber
.LP
IntegerValue ::= SignedNumber\ |\ identifier
.LP
EnumeratedType ::= ENUMERATED {Enumeration}
.LP
Enumeration ::=
.LP
NamedNumber\ |
.LP
NamedNumber, Enumeration
.LP
EnumeratedValue ::= identifier
.LP
RealType ::= REAL
.LP
RealValue ::= NumericRealValue\ |\ SpecialRealValue
.LP
NumericRealValue ::= {Mantissa, Base, Exponent}\ |\ 0
.LP
Mantissa ::= SignedNumber
.LP
Base ::= 2\ |\ 10
.LP
Exponent ::= SignedNumber
.LP
SpecialRealValue ::= PLUS\(hyINFINITY\ |\ MINUS\(hyINFINITY
.LP
BitStringType ::= BIT STRING\ |\ BIT STRING {NamedBitList}
.LP
NamedBitList ::= NamedBit\ |\ NamedBitList,NamedBit
.LP
NamedBit ::=
.LP
identifier(number)\ |
.LP
identifier(DefinedValue)
.bp
.LP
BitStringValue ::= bstring\ |\ hstring\ |{IdentifierList}\ |\ {\|}
.LP
IdentifierList ::= identifier\ |\ IdentifierList,identifier
.LP
OctetStringType ::= OCTET STRING
.LP
OctetStringValue ::= bstring\ |\ hstring
.LP
NullType ::= NULL
.LP
NullValue ::= NULL
.LP
SequenceType ::=
.LP
SEQUENCE {ElementTypeList}\ |
.LP
SEQUENCE {\|}
.LP
ElementTypeList ::=
.LP
ElementType\ |
.LP
ElementTypeList,ElementType
.LP
ElementType ::=
.LP
NamedType\ |
.LP
NamedType OPTIONAL\ |
.LP
NamedType DEFAULT Value\ |
.LP
COMPONENTS OF Type
.LP
SequenceValue ::= {ElementValueList}\ |\ {\|}
.LP
ElementValueList ::=
.LP
NamedValue\ |
.LP
ElementValueList,NamedValue
.LP
SequenceOfType ::= SEQUENCE OF Type\ |\ SEQUENCE
.LP
SequenceOfValue ::= {ValueList}\ |\ {\|}
.LP
ValueList ::= Value\ |\ ValueList,Value
.LP
SetType ::= SET{ElementTypeList}\ |\ SET {\|}
.LP
SetValue ::= {ElementValueList}\ |\ {\|}
.LP
SetOfType ::= SET OF Type\ |\ SET
.LP
SetOfValue ::= {ValueList}\ |\ {\|}
.LP
ChoiceType ::= CHOICE{AlternativeTypeList}
.LP
AlternativeTypeList ::=
.LP
NamedType\ |
.LP
AlternativeTypeList,NamedType
.LP
ChoiceValue ::= NamedValue
.LP
SelectionType ::= identifier < Type
.LP
SelectionValue ::= NamedValue
.LP
TaggedType ::=
.LP
Tag Type\ |
.LP
Tag IMPLICIT Type\ |
.LP
Tag EXPLICIT Type
.LP
Tag ::= [Class ClassNumber]
.LP
ClassNumber ::= number\ |\ DefinedValue
.LP
Class ::=
.LP
UNIVERSAL\ |
.LP
APPLICATION\ |
.LP
PRIVATE\ |
.LP
empty
.bp
.LP
TaggedValue ::= Value
.LP
AnyType ::=
.LP
ANY\ |
.LP
ANY DEFINED BY identifier
.LP
AnyValue ::= Type Value
.LP
ObjectIdentifierType ::= OBJECT IDENTIFIER
.LP
ObjectIdentifierValue ::=
.LP
{ObjIdComponentList}\ |
.LP
{DefinedValue ObjIdComponentList}
.LP
ObjIdComponentList ::=
.LP
ObjIdComponent\ |
.LP
ObjIdComponent ObjIdComponentList
.LP
ObjIdComponent ::=
.LP
NameForm\ |
.LP
NumberForm\ |
.LP
NameAndNumberForm
.LP
NameForm ::= identifier
.LP
NumberForm ::= number\ |\ DefinedValue
.LP
NameAndNumberForm ::= identifier(NumberForm)
.LP
CharacterStringType ::= typereference
.LP
CharacterStringValue ::= cstring
.LP
UsefulType ::= typereference
.PP
The following characterstring types are defined in section two:
.LP
NumericString
VisibleString
.LP
PrintableString
ISO646String
.LP
TeletexString
IA5String
.LP
T61String
GraphicString
.LP
VideotexString
GeneralString
.PP
The following useful types are defined in section three:
.LP
GeneralizedTime
EXTERNAL
.LP
UTCTime
ObjectDescriptor
.PP
The following productions are used in section four:
.LP
Subtype ::=
.LP
ParentType SubtypeSpec\ |
.LP
SET SizeConstraint OF Type\ |
.LP
SEQUENCE SizeConstraint OF Type
.LP
ParentType ::= Type
.LP
SubtypeSpec ::=
.LP
(SubtypeValueSet SubtypeValueSetList)
.LP
SubtypeValueSetList ::=
.LP
\*Q|\*U
.LP
SubtypeValueSet
.LP
SubtypeValueSetList\ |
.LP
empty
.LP
SubtypeValueSet ::=
.LP
SingleValue\ |
.LP
ContainedSubtype\ |
.LP
ValueRange\ |
.LP
PermittedAlphabet\ |\ SizeConstraint\ |\ InnerTypeConstraint
.LP
SingleValue ::= Value
.LP
ContainedSubtype ::= INCLUDES Type
.LP
ValueRange ::= LowerEndPoint\ .\|.\ UpperEndPoint
.bp
.LP
LowerEndpoint ::= LowerEndValue\ |\ LowerEndValue <
.LP
UpperEndpoint ::= UpperEndValue\ |\ <UpperEndValue
.LP
LowerEndValue ::= Value\ |\ MIN
.LP
UpperEndValue ::= Value\ |\ MAX
.LP
SizeConstraint ::= SIZE SubtypeSpec
.LP
PermittedAlphabet ::= FROM SubtypeSpec
.LP
InnerTypeConstraints ::=
.LP
WITH\ COMPONENT SingleTypeConstraint\ |
.LP
WITH\ COMPONENTS MultipleTypeConstraints
.LP
SingleTypeConstraint ::= SubtypeSpec
.LP
MultipleTypeConstraints ::=
.LP
FullSpecification\ |\ PartialSpecification
.LP
FullSpecification ::= {TypeConstraints}
.LP
PartialSpecification ::= {.\|.\|., TypeConstraints}
.LP
TypeConstraints ::=
.LP
NamedConstraint\ |
.LP
NamedConstraint, TypeConstraints
.LP
NamedConstraint ::= identifier Constraint\ |\ Constraint
.LP
Constraint ::= ValueConstraint PresenceConstraint
.LP
ValueConstraint ::= SubtypeSpec\ |\ empty
.LP
PresenceConstraint ::= PRESENT\ |\ ABSENT\ |\ empty\ |\ OPTIONAL
.PP
The following additional items are defined in \(sc A.2 for use
in the macro notation:
.LP
macroreference
\*Qnumber\*U
.LP
productionreference
\*Qempty\*U
.LP
localtypereference
MACRO
.LP
localvaluereference
TYPE
.LP
\*Q|\*U
NOTATION
.LP
>
VALUE
.LP
astring
value
.LP
\*Qstring\*U
type
.LP
\*Qidentifier\*U
.PP
The following productions are used in Annex A, with the above
items, and items listed at the head of this appendix, as terminal symbols:
.LP
MacroDefinition ::=
.LP
macroreference
.LP
MACRO
.LP
\*Q::=\*U
.LP
MacroSubstance
.LP
MacroSubstance ::=
.LP
BEGIN MacroBody END\ |
.LP
macroreference\ |
.LP
Externalmacroreference
.LP
MacroBody ::=
.LP
TypeProduction
.LP
ValueProduction
.LP
SupportingProductions
.LP
TypeProduction ::=
.LP
TYPE NOTATION
.LP
\*Q::=\*U
.LP
MacroAlternativeList
.bp
.LP
ValueProduction ::=
.LP
VALUE NOTATION
.LP
\*Q::=\*U
.LP
MacroAlternativeList
.LP
SupportingProductions ::= ProductionList\ |\ empty
.LP
ProductionList ::= Production\ |\ ProductionList Production
.LP
Production ::=
.LP
productionreference
.LP
\*Q::=\*U
.LP
MacroAlternativeList
.LP
Externalmacroreference ::=
.LP
modulereference\|.\|macroreference
.LP
MacroAlternativeList ::=
.LP
MacroAlternative\ |
.LP
MacroAlternativeList \*Q|\*U MacroAlternative
.LP
MacroAlternative ::= SymbolList
.LP
SymbolList ::= SymbolElement\ |\ SymbolList SymbolElement
.LP
SymbolElement ::= SymbolDefn\ |\ EmbeddedDefinitions
.LP
SymbolDefn ::=
.LP
astring\ |
.LP
productionreference\ |
.LP
\*Qstring\*U\ |
.LP
\*Qidentifier\*U\ |
.LP
\*Qnumber\*U\ |
.LP
\*Qempty\*U\ |
.LP
type\ |
.LP
type(localtypereference)\ |
.LP
value(MacroType)\ |
.LP
value(localvaluereference MacroType)\ |
.LP
value(VALUE MacroType)
.LP
MacroType ::= localtypereference\ |\ Type
.LP
EmbeddedDefinitions ::= <EmbeddedDefinitionList>
.LP
EmbeddedDefinitionList ::=
.LP
EmbeddedDefinition\ |
.LP
EmbeddedDefinitionList EmbeddedDefinition
.LP
EmbeddedDefinition ::=
.LP
LocalTypeassignment\ |
.LP
LocalValueassignment
.LP
LocalTypeassignment ::=
.LP
Localtypereference
.LP
\*Q::=\*U
.LP
MacroType
.LP
LocalValueassignment ::=
.LP
localvaluereference
.LP
MacroType
.LP
\*Q::=\*U
.LP
MacroValue
.LP
MacroValue ::= Value\ |\ localvaluereference
.bp
.sp 2P
.LP
\fBRecommendation\ X.209\fR
.RT
.sp 2P
.ce 1000
\fBSPECIFICATION\ OF\ BASIC\ ENCODING\ RULES\ FOR\fR
.EF '% Fascicle\ VIII.4\ \(em\ Rec.\ X.209''
.OF '''Fascicle\ VIII.4\ \(em\ Rec.\ X.209 %'
.ce 0
.sp 1P
.ce 1000
\fBABSTRACT\ SYNTAX\ NOTATION\ ONE\ (ASN.1)\fR
.FS
Recommendation\ X.209 and ISO 8825 [Information processing systems \(em\
Open systems interconnection\ \(em Specification of basic encoding rules
for abstract Syntax Notation One\ (ASN.1)] as extended by Addendum\ 1 to
ISO\ 8825, were developed in close cooperation and are technically aligned.
.FE
.ce 0
.sp 1P
.ce 1000
\fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
the variety and complexity of information objects
conveyed within the application layer;
.PP
(b)
the need for a high\(hylevel notation for specifying such information objects;
.PP
(c)
the value of isolating and standardizing the rules for encoding such information
objects.
.sp 1P
.LP
\fIunanimously recommends\fR
.sp 9p
.RT
.PP
that the rules for encoding information objects are defined in
this Recommendation.
.sp 1P
.ce 1000
CONTENTS
.ce 0
.sp 1P
.sp 2P
.LP
0
\fIIntroduction\fR
.sp 1P
.RT
.sp 1P
.LP
1
\fIScope and field of application\fR
.sp 9p
.RT
.sp 1P
.LP
2
\fIReferences\fR
.sp 9p
.RT
.sp 1P
.LP
3
\fIDefinitions\fR
.sp 9p
.RT
.sp 1P
.LP
4
\fIAbbreviations and notation\fR
.sp 9p
.RT
.LP
4.1
Abbreviations
.LP
4.2
Notation
.sp 1P
.LP
5
\fIConformance\fR
.sp 9p
.RT
.sp 1P
.LP
6
\fIGeneral rules for encoding\fR
.sp 9p
.RT
.LP
6.1
Structure of an encoding
.LP
6.2
Identifier octets
.LP
6.3
Length octets
.LP
6.4
Contents octets
.LP
6.5
End\(hyof\(hycontents octets
.sp 1P
.LP
7
\fIEncoding of a Boolean value\fR
.sp 9p
.RT
.sp 1P
.LP
8
\fIEncoding of an integer value\fR
.sp 9p
.RT
.sp 1P
.LP
9
\fIEncoding of an enumerated value\fR
.sp 9p
.RT
.sp 1P
.LP
10
\fIEncoding of a real value\fR
.sp 9p
.RT
.sp 1P
.LP
11
\fIEncoding of a bitstring value\fR .bp
.sp 9p
.RT
.sp 1P
.LP
12
\fIEncoding of an octetstring value\fR
.sp 9p
.RT
.sp 1P
.LP
13
\fIEncoding of a null value\fR
.sp 9p
.RT
.sp 1P
.LP
14
\fIEncoding of a sequence value\fR
.sp 9p
.RT
.sp 1P
.LP
15
\fIEncoding of a sequence\(hyof value\fR
.sp 9p
.RT
.sp 1P
.LP
16
\fIEncoding of a set value\fR
.sp 9p
.RT
.sp 1P
.LP
17
\fIEncoding of a set\(hyof value\fR
.sp 9p
.RT
.sp 1P
.LP
18
\fIEncoding of a choice value\fR
.sp 9p
.RT
.sp 1P
.LP
19
\fIEncoding of a selection value\fR
.sp 9p
.RT
.sp 1P
.LP
20
\fIEncoding of a tagged value\fR
.sp 9p
.RT
.sp 1P
.LP
21
\fIEncoding of a value of the ANY type\fR
.sp 9p
.RT
.sp 1P
.LP
22
\fIEncoding of an object identifier value\fR
.sp 9p
.RT
.sp 1P
.LP
23
\fIEncoding for values of the character string types\fR
.sp 9p
.RT
.sp 1P
.LP
24
\fIEncoding for values of the ASN.1 useful types\fR
.sp 9p
.RT
.sp 1P
.LP
25
\fIUse in transfer syntax definition\fR
.sp 9p
.RT
.sp 1P
.LP
\fIAppendix\ I\fR \ \(em\ Example of encodings
.sp 9p
.RT
.LP
I.1
ASN.1 description of the record structure
.LP
I.2
ASN.1 description of a record value
.LP
I.3
Representation of this record value
.sp 1P
.LP
\fIAppendix\ II\fR \ \(em\ Assignment of object identifier values
.sp 9p
.RT
.sp 1P
.LP
\fIAppendix\ III\fR \ \(em\ Illustration of real value encoding
.sp 9p
.RT
.sp 2P
.LP
\fB0\fR \fBIntroduction\fR
.sp 1P
.RT
.PP
Recommendation X.208 (Specification of Abstract Syntax Notation
One) specifies a notation for the definition of abstract syntaxes, enabling
application layer specifications to define the types of information they
need to transfer using the presentation service. It also specifies a notation
for
the specification of value of a defined type.
.PP
This Recommendation defines a set of encoding rules that may be
applied to values of types defined using the notation specified in
Recommendation\ X.208. Application of these encoding rules produces a transfer
syntax for such values. It is implicit in the specification of these encoding
rules that they are also to be used for decoding.
.PP
There may be more than one set of encoding rules that can be applied to
values of types that are defined using the notation of Recommendation\
X.208. This Recommendation defines one set of encoding rules, called \fBbasic
encoding\fR \fBrules\fR .
.PP
This Recommendation is technically and editorially aligned with ISO
8825 plus Addendum\ 1 to ISO\ 8825.
.PP
Appendix I gives examples of the application of the encoding rules. It
is not part of this Recommendation.
.PP
Appendix II summarises the assignment of object identifier values made
in this Recommendation and is not part of this Recommendation.
.PP
Appendix III is not part of this Recommendation, and gives examples of
applying the rules for encoding reals.
.bp
.RT
.sp 2P
.LP
\fB1\fR \fBScope and field of application\fR
.sp 1P
.RT
.PP
This Recommendation specifies a set of basic encoding rules that
may be used to derive the specification of a transfer syntax for values of
types defined using the notation specified in Recommendation\ X.208. These
basic encoding rules are also to be applied for decoding such a transfer
syntax in
order to identify the data values being transferred.
.PP
These basic encoding rules are used at the time of communication (by the
presentation service provider when required by a presentation
context).
.RT
.sp 2P
.LP
\fB2\fR \fBReferences\fR
.sp 1P
.RT
.LP
[1]
Recommendation X.200, \fIReference Model of Open Systems Interconnection\fR
\fIfor CCITT Applications\fR (see also ISO\ 7498).
.LP
[2]
Recommendation X.208, \fISpecification of Abstract Syntax Notation One\fR
\fI(ASN.1)\fR (see also ISO\ 8824).
.LP
[3]
Recommendation X.226, \fIPresentation Protocol Specification for Open\fR
\fISystems Interconnection for CCITT Applications\fR (see also ISO\ 8823).
.LP
[4]
ISO 2022, \fIInformation processing\ \(em\ ISO\ 7\(hybit and 8\(hybit
coded\fR
\fIcharacter sets\fR \ \(em\ \fICode extension techniques\fR .
.LP
[5]
ISO 2375, \fIData processing\fR \ \(em\ \fIProcedure for registration
of escape\fR
\fIsequences\fR .
.LP
[6]
ISO 6093, \fIInformation processing\fR \ \(em\ \fIRepresentation of numerical\fR
\fIvalues in character strings for information interchange\fR .
.sp 2P
.LP
\fB3\fR \fBDefinitions\fR
.sp 1P
.RT
.PP
The definitions of Recommendation X.208 are used in this
Recommendation.
.RT
.sp 1P
.LP
3.1
\fBdynamic conformance\fR
.sp 9p
.RT
.PP
A statement of the requirement for an implementation to adhere to the behaviour
prescribed by this Recommendation in an instance of
communication.
.RT
.sp 1P
.LP
3.2
\fBstatic conformance\fR
.sp 9p
.RT
.PP
A statement of the requirement for support by an implementation of a valid
set of features from among those defined by this Recommendation.
.RT
.sp 1P
.LP
3.3
\fBdata value\fR
.sp 9p
.RT
.PP
Information specified as the value of a type; the type and the
value are defined using ASN.1.
.RT
.sp 1P
.LP
3.4
\fBencoding (of a data value)\fR
.sp 9p
.RT
.PP
The complete sequence of octets used to represent the data
value.
.PP
\fINote\fR \ \(em\ Some CCITT Recommendations use the term \*Qdata element\*U
for
this sequence of octets, but the term is not used in this Recommendation, as
ISO International Standard use it to mean \*Qdata value\*U.
.RT
.sp 1P
.LP
3.5
\fBidentifier octets\fR
.sp 9p
.RT
.PP
Part of a data value encoding which is used to identify the type of the
value.
.RT
.sp 1P
.LP
3.6
\fBlength octets\fR
.sp 9p
.RT
.PP
Part of a data value encoding following the identifier octets
which is used to determine the end of the encoding.
.RT
.sp 1P
.LP
3.7
\fBend\(hyof\(hycontents octets\fR
.sp 9p
.RT
.PP
Part of a data value encoding, occurring at its end, which is used to determine
the end of the encoding.
.PP
\fINote\fR \ \(em\ Not all encodings require end\(hyof\(hycontents octets.
.bp
.RT
.sp 1P
.LP
3.8
\fBcontents octets\fR
.sp 9p
.RT
.PP
That part of a data value encoding which represents a particular value,
to distinguish it from other values of the same type.
.RT
.sp 1P
.LP
3.9
\fBprimitive encoding\fR
.sp 9p
.RT
.PP
A data value encoding in which the contents octets directly
represent the value.
.RT
.sp 1P
.LP
3.10
\fBconstructed encoding\fR
.sp 9p
.RT
.PP
A data value encoding in which the contents octets are the
complete encoding of one or more other data values.
.RT
.sp 1P
.LP
3.11
\fBsender\fR
.sp 9p
.RT
.PP
An implementation encoding a data value for transfer.
.RT
.sp 1P
.LP
3.12
\fBreceiver\fR
.sp 9p
.RT
.PP
An implementation decoding the octets produced by a sender, in
order to identify the datavalue which was encoded.
.RT
.sp 2P
.LP
\fB4\fR \fBAbbrevistions and notation\fR
.sp 1P
.RT
.sp 1P
.LP
4.1
\fIAbbreviations\fR
.sp 9p
.RT
.LP
ASN.1
Abstract Syntax Notation One
.sp 2P
.LP
4.2
\fINotation\fR
.sp 1P
.RT
.PP
4.2.1
This Recommendation references the notation defined by
Recommendation\ X.208.
.sp 9p
.RT
.PP
4.2.2
This Recommendation specifies the value of each octet in an
encoding by use of the terms \*Qmost significant bit\*U and \*Qleast significant
bit\*U.
.PP
\fINote\fR \ \(em\ Lower layer specifications use the same notation to
define the order of bit transmission on a serial line, or the assignment of
bits to parallel channels.
.PP
4.2.3
For the purposes of this Recommendation, the bits of an octet are numbered
from 8 to 1, where bit\ 8 is the \*Qmost significant bit\*U, and bit\ 1
is the \*Qleast significant bit\*U.
.sp 9p
.RT
.sp 2P
.LP
\fB5\fR \fBConformance\fR
.sp 1P
.RT
.PP
5.1
Dynamic conformance is specified by \(sc\ 6 to \(sc\ 24 inclusive.
.sp 9p
.RT
.PP
5.2
Static conformance is specified by those documents which specify the application
of these basic encoding rules.
.PP
5.3
Alternative encodings are permitted by this Recommendation as a
sender's option. Conforming receivers shall support all alternatives.
.PP
\fINote\fR \ \(em\ Examples of such alternative encodings appear in
\(sc\ 6.3.2\|b) and Table\ 2/X.209.
.sp 2P
.LP
\fB6\fR \fBGeneral rules for encoding\fR
.sp 1P
.RT
.sp 1P
.LP
6.1
\fIStructure of an encoding\fR
.sp 9p
.RT
.PP
6.1.1
The encoding of a data value shall consist of four components
which shalll appear in the following order:
.sp 9p
.RT
.LP
a)
identifier octets (see \(sc\ 6.2);
.LP
b)
length octets (see \(sc\ 6.3);
.LP
c)
contents octets (see \(sc\ 6.4);
.LP
d)
end\(hyof\(hycontents octets (see \(sc\ 6.5).
.bp
.PP
6.1.2
The end\(hyof\(hycontents octets shall not be present unless the value
of the length octets requires them to be present (see \(sc\ 6.3).
.sp 9p
.RT
.PP
6.1.3
Figure 1/X.209 illustrates the structure of an encoding (primitive or constructed).
Figure\ 2/X.209 illustrates an alternative constructed
encoding.
.sp 2P
.LP
6.2
\fIIdentifier octets\fR
.sp 1P
.RT
.PP
6.2.1
The identifier octets shall encode the ASN.1 tag (class and
number) of the type of the data value.
.sp 9p
.RT
.PP
6.2.2
For tags with a number ranging from zero to 30 (inclusive), the
identifier octets shall comprise a single octets encoded as follows:
.LP
a)
bits 8 and 7 shall be encoded to represent the clas of the
tag as specified in Table\ 1/X.209;
.LP
b)
bit 6 shall be a zero or a one according to the rules of
\(sc\ 6.2.5;
.LP
c)
bit 5 to 1 shall encode the number of the tag as a binary
integer with bit 5 as the most significant bit.
.PP
6.2.3
Figure 3/X.209 illustrates the form of an identifier octet for a type with
a tag whose number is in the range zero to 30 (inclusive).
.sp 9p
.RT
.PP
6.2.4
For tags with a number greater than or equal to 31, the identifier shall
comprise a leading octet followed by one or more subsequent octets.
.ce
\fBH.T. [T1.209]\fR
.ce
TABLE\ 1/X.209
.ce
\fBEncoding of class of tag\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) | cw(24p) | cw(24p) .
Class Bit 8 Bit 7
_
.T&
lw(72p) | cw(24p) | cw(24p) .
Universal 0 0
.T&
lw(72p) | cw(24p) | cw(24p) .
Application 0 1
.T&
lw(72p) | cw(24p) | cw(24p) .
Context\(hyspecific 1 0
.T&
lw(72p) | cw(24p) | cw(24p) .
Private 1 1
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 1/X.209 [T1.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
6.2.4.1
The leading octet shall be encoded as follows:
.sp 9p
.RT
.LP
a)
bits 8 and 7 shall be encoded to represent the class of the
tags as listed in Table\ 1/X.209;
.LP
b)
bit 6 shall be a zero or a one according to the rule of
\(sc\ 6.2.5;
.LP
c)
bit 5 to 1 shall be encoded as 11111\d2\u.
.LP
.rs
.sp 14P
.ad r
\fBFigure 1/X.209, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 14P
.ad r
\fBFigure 2/X.209, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
6.2.4.2
The subsequent octets shall encode the number of the tag as
follows:
.LP
a)
bit 8 of each octet shall be set to one unless it is the
last octet of the identifier octets;
.LP
b)
bit 7 to 1 of the first subsequent octet, followed by bits\ 7
to 1 of the second subsequent octet, followed in turn by bits\ 7 to\ 1
of each further octet, up to and including the last subsequent octet
in the identifier octets shall be the encoding of an unsigned binary
integer equal to the tag number, with bit\ 7 of the first subsequent
octet as the most significant bit;
.LP
c)
bits 7 to 1 of the first subsequent octet shall not all be
zero.
.PP
6.2.4.3
Figure 4/X.209 illustrates the form of the identifier octets for a type
with a tag whose number is greater than\ 30.
.sp 9p
.RT
.PP
6.2.5
Bit 6 shall be set to zero if the encoding is primitive, and shall be set
to one if the encoding is constructed.
.PP
\fINote\fR \ \(em\ Subsequent clauses specify whether the encoding is
primitive or constructed for each type.
.LP
.rs
.sp 14P
.ad r
\fBFigure 3/X.209, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 14P
.ad r
\fBFigure 4/X.209, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
6.2.6
Recommendation X.208 specifies that the tag of a type defined
using the \*QCHOICE\*U keyword takes the value of the tag of the type from
which
the chosen data value is taken.
.sp 9p
.RT
.PP
6.2.7
Recommendation X.208 specifies that the tag of a type defined
using \*QANY\*U is indeterminate. The \*QANY\*U type is subsequently defined
to be an ASN.1 type, and the complete encoding is then identical to that
of a value of the assigned type (including the identifier octets).
.sp 2P
.LP
6.3
\fILength octets\fR
.sp 1P
.RT
.PP
6.3.1
Two forms of length octets specified. These are
.sp 9p
.RT
.LP
a)
the definite form (see \(sc 6.3.3); and
.LP
b)
the indefinite form (see \(sc\ 6.3.4).
.PP
6.3.2
A sender shall
.sp 9p
.RT
.LP
a)
use the definite form (\(sc 6.3.3) if the encoding is
primitive;
.LP
b)
use either the definite form (\(sc 6.3.3) or the indefinite
form (\(sc 6.3.4), a sender's option, if the encoding is constructed and
all immediately available;
.LP
c)
use the indefinite form (\(sc\ 6.3.4) if the encoding is
constructed and is not all immediately available.
.PP
6.3.3
For the definite form, the length octets shall consist of one or more octets,
and shall represent the number of octets in the contents octets
using either the short form (\(sc\ 6.3.3.1) or the long form (\(sc\ 6.3.3.2)
as a
sender's option.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ The short form can only be used if the number of octets
in the contents octets is less than or equal to\ 127.
.PP
6.3.3.1
In the short form, the length octets shall consist of a single octet in
which bit 8 is zero and bit\ 7 to\ 1 encode the number of octets in the
contents octets (which may be zero), as an unsigned binary integer with
bit\ 7 as the most significant bit.
.sp 9p
.RT
.LP
\fIExample:\fR
.LP
L\ =\ 38 can be encoded as 00100110\d2\u
.PP
6.3.3.2
In the long form, the length octets shall consist of an initial octet and
one or more subsequent octets. The initial octet shall be encoded as follows:
.sp 9p
.RT
.LP
a)
bit 8 shall be one;
.LP
b)
bits 7 to 1 shall encode the number of subsequent octets
in the length octets, as an unsigned binary integer with bit\ 7 as the
most significant bit;
.LP
c)
the value 11111111\d2\ushall not be used
.PP
\fINote\fR \ \(em\ This restriction is introduced for possible future
extension.
.bp
.PP
Bits 8 to 1 of the first subsequent octet, followed by bits 8 to 1 of the
second subsequent octet, followed in turn by bits\ 8 to\ 1 of each further
octet up to and including the last subsequent octet, shall be the encoding
of an unsigned binary integer equal to the number of octets in the contents
octets, with bit\ 8 of the first subsequent octet as the most significant
bit.
.RT
.LP
\fIExample:\fR
.LP
L\ =\ 201 can be encoded as:\ 10000001\d2\u
.LP
L\ =\ 201 can be encoded as:
\ 11001001\d2\u
.PP
\fINote\fR \ \(em\ In the long form, it is a sender's option whether to
use more length octets than the minimum necessary.
.PP
6.3.4
For the indefinite form, the length octets indicate that the
contents are terminated by end\(hyof\(hycontents octets (see \(sc\ 6.5),
and shall
consist of a single octet.
.sp 9p
.RT
.PP
6.3.4.1
The single octet shall have bit 8 set to one, and bits 7 to\ 1 set to zero.
.PP
6.3.4.2
If this form of length is used, then end\(hyof\(hycontents octets (see
\(sc\ 6.5) shall be present in the encoding following the contents octets.
.sp 1P
.LP
6.4
\fIContents octets\fR
.sp 9p
.RT
.PP
The contents octets shall consist of zero, one or more octets, and shall
encode the data value as specified in subsequent clauses.
.PP
\fINote\fR \ \(em\ The contents octets depend on the type of the data value;
subsequent clauses follow the same sequence as the definition of types in
ASN.1.
.RT
.sp 1P
.LP
6.5
\fIEnd\(hyof\(hycontents octets\fR
.sp 9p
.RT
.PP
The end\(hyof\(hycontents octets shall be present if the length is
encoded as specified in \(sc\ 6.3.4, otherwise they shall not be present.
.PP
The end\(hyof\(hycontents octets shall consist of two zero octets.
.PP
\fINote\fR \ \(em\ The end\(hyof\(hycontents octets can be considered as
the encoding of a value whose tag is universal, whose form is primitive,
whose number of the tag is zero, and whose contents is absent, thus:
.RT
.LP
End\(hyof\(hycontents
Length
Contents
.LP
00\d1\\d6\u 00\d1\\d6\u Absent
.sp 2P
.LP
\fB7\fR \fBEncoding of a Boolean value\fR
.sp 1P
.RT
.PP
7.1
The encoding of a Boolean value shall be primitive. The contents octets
shall consist of a single octet.
.sp 9p
.RT
.PP
7.2
If the Boolean value is
.sp 1P
.ce 1000
FALSE
.ce 0
.sp 1P
.LP
the octet shall be zero.
.PP
7.2.1
If the Boolean value is
.sp 9p
.RT
.sp 1P
.ce 1000
TRUE
.ce 0
.sp 1P
.LP
the octet shall have any non\(hyzero value, as a sender's option.
.LP
\fIExample\fR \ \(em\ If of type BOOLEAN, the value TRUE can be encoded as:
.LP
Boolean
Length
Contents
.LP
01\d1\\d6\u 01\d1\\d6\u
FF\d1\\d6\u
.sp 2P
.LP
\fB8\fR \fBEncoding of an integer value\fR
.sp 1P
.RT
.PP
8.1
The encoding of an integer value shall be primitive. The contents octets
shall consist of one or more octets.
.bp
.sp 9p
.RT
.PP
8.2
If the contents octets of an integer value encoding consist of
more than one octet, then the bits of the first octet and bit\ 8 of the
second octet
.LP
a)
shall not all be ones; and
.LP
b)
shall not all be zero.
.PP
\fINote\fR \ \(em\ These rules ensure that an integer value is always
encoded in the smallest possible number of octets.
.PP
8.3
The contents octets shall be a two's complement binary number
equal to the integer value, and consisting of bits\ 8 to\ 1 of the first
octet, followed by bits\ 8 to\ 1 of the second octet, followed by bits\
8 to\ 1 of each
octet in turn up to and including the last octet of the contents octets.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ The value of a two's complement binary number is derived
by numbering the bits in the contents octets, starting with bit\ 1 of the
last octet as bit zero and ending the numbering with bit\ 8 of the first
octet. Each bit is assigned a numerical value of 2\uN\d, where N is its
position in the
above numbering sequence. The value of the two's complement binary number is
obtained by summing the numerical values assigned to each bit for those bits
which are set to one, excluding bit\ 8 of the first octet, and then reducing
this value by the numerical value assigned to bit\ 8 of the first octet
if that bit is set to one.
.sp 2P
.LP
\fB9\fR \fBEncoding of an enumerated value\fR
.sp 1P
.RT
.PP
9.1
The encoding of an enumerated value shall be that of the integer value
with which it is associated.
.sp 9p
.RT
.sp 2P
.LP
\fB10\fR \fBEncoding of a real value\fR
.sp 1P
.RT
.PP
10.1
The encoding of a real value shall be primitive.
.sp 9p
.RT
.PP
10.2
If the real value is the value zero, there shall be no contents
octets in the encoding.
.PP
10.3
If the real value is non\(hyzero, then the base used for the encoding shall
be B', chosen by the sender. If B' is 2, 8 or\ 16, a
binary encoding, specified in \(sc\ 10.5, shall be used. If B' is\ 10, a
character encoding, specified in \(sc\ 10.6, shall be used.
.PP
\fINote\fR \ \(em\ The form of storage, generation, or processing by senders
and receivers, and the form used in the ASN.1 value notation are all
independent of the base used for transfer.
.PP
10.4
Bit 8 of the first contents octet shall be set as follows:
.sp 9p
.RT
.LP
a)
if bit 8 = 1, then the binary encoding specified in \(sc\ 10.5 applies;
.LP
b)
if bit 8 = 0 and bit 7 = 0, then the decimal encoding
specified in \(sc\ 10.6 applies;
.LP
c)
if bit 8 = 0 and bit 7 = 1, then a \*QSpecialRealValue\*U (see Recommendation\
X.208) is encoded as specified in \(sc\ 10.7.
.PP
10.5
When binary encoding is used (bit 8 = 1), then if the mantissa, M is non\(hyzero,
it shall be represented by a sign\ S, a non\(hynegative integer
value\ N and a binary scaling factor\ F, such that
\v'6p'
.sp 9p
.RT
.sp 1P
.ce 1000
M = S X N X 2\uF\d, 0 \(= F < 4, S = +1 or \(em1
.ce 0
.sp 1P
.PP
.sp 1
\fINote\fR \ \(em\ This freedom to choose F is provided to enable easier
generation of the transfer format by eliminating the need to align the
implied decimal point of the mantissa with an octet boundary (see Appendix\
III). The
existence of F does not noticeably complicate the task of receivers.
.PP
10.5.1
Bit 7 of the first contents octets shall be 1 if S is \(em1 and 0
otherwise.
.bp
.sp 9p
.RT
.PP
10.5.2
Bits 6 to 5 of the first contents octets shall encode the value of the
base B' as follows:
.ce
\fBH.T. [T2.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(30p) | cw(60p) .
Bits 6 to 5 Base
_
.T&
cw(30p) | lw(60p) .
00 base 2
.T&
cw(30p) | lw(60p) .
01 base 8
.T&
cw(30p) | lw(60p) .
10 base 16
.T&
cw(30p) | lw(60p) .
11 T{
Reserved for future versions of this
Recommendation
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable [T2.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
10.5.3
Bits 4 to 3 of the first contents octet shall encode the value of the binary
scaling factor F as an unsigned binary integer.
.PP
10.5.4
Bits 2 to 1 of the first contents octet shall encode the format of the
exponent as follows:
.LP
a)
if bits 2 to 1 are 00, then the second contents octet
encodes the value of the exponent as a two's complement binary
number;
.LP
b)
if bits 2 to 1 are 01, then the second and third contents
octets encode the value of the exponents as a two's complement binary
number;
.LP
c)
if bits 2 to 1 are 10, then the second, third and fourth
contents octets encode the value of the exponent as a two's complement
binary number;
.LP
d)
if bits 2 to 1 are 11, then the second contents octet
encodes the number of octets, X say, (as an unsigned binary number)
used to encode the value of the exponent, and the third up to the
(X\ plus\ 3)\ut\d\uh\d (inclusive) contents octets encode the value of
the exponent as a two's complement binary number; the value of
X\ shall be at least one; the first nine bits of the transmitted
exponent shall not be all zeros or all ones.
.PP
10.5.5
The remaining contents octets encode the value of the integer N
(see \(sc\ 10.5) as an unsigned binary number.
.sp 9p
.RT
.PP
\fINote\ 1\fR \ \(em\ This encoding does not specify a \*Qnormalized\*U
representation, there being a number of possible representations of each
value (except zero). This variation is a senders option, and can be used
as a broad indication of precision.
.PP
\fINote\ 2\fR \ \(em\ This representation of real numbers is very different
from the formats normally used in floating point hardware, but has been
designed to be easily converted to and from such formats (see Appendix\
III).
.RT
.PP
10.6
When decimal encoding is used (bits 8 to 7 = 00), all the contents octets
following the first contents octet form a field, as the term is used in
ISO\ 6093, of a length chosen by the sender, and encoded according to ISO\
6093. The choice of ISO 6093 number representation is specified by bits\
6 to\ 1 of the first contents octet as follows:
.sp 9p
.RT
.ce
\fBH.T. [T3.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(30p) | cw(60p) .
Bits 6 to 1 Number representation
_
.T&
cw(30p) | lw(60p) .
00 0001 ISO 6093 NR1 form
.T&
cw(30p) | lw(60p) .
00 0010 ISO 6093 NR2 form
.T&
cw(30p) | lw(60p) .
00 0011 ISO 6093 NR3 form
_
.TE
.nr PS 9
.RT
.ad r
\fBTable [T3.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
The remaining values of bits 6 to 1 are reserved for future
versions of this Recommendation.
.PP
\fINote\ 1\fR \ \(em\ The Recommendation in ISO 6093 concerning the user of at
least one digit to the left of the decimal mark are also recommended in this
Recommendation, but are not mandatory.
.PP
\fINote\ 2\fR \ \(em\ There shall be no use of scaling factors specified in
accompanying documentation (see ISO\ 6093).
.PP
\fINote\ 3\fR \ \(em\ Use of the normalised form (see ISO 6093) is a senders
option, and has no significance.
.bp
.RT
.PP
10.7
When \*QSpecialRealValues\*U are to be encoded (bits 8 to 7 = 01),
there shall be only one contents octet, with values as follows:
.sp 9p
.RT
.LP
01000000\ \ \ Value is PLUS\(hyINFINITY
.LP
01000001\ \ \ Value is MINUS\(hyINFINITY
.PP
All other values having bit 8 and 7 equal to 0 and 1 respectively are reserved
for future versions of this Recommendation.
.sp 2P
.LP
\fB11\fR \fBEncoding of a bitstring value\fR
.sp 1P
.RT
.PP
11.1
The encoding of a bitstring value shall be either primitive or
constructed at the option of the sender.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ Where it is necessary to transfer part of a bit string
before the entire bitstring is available, the constructed encoding is used.
.PP
11.2
The contents octets for the primitive encoding shall contain an
initial octet followed by zero, one or more subsequent octets.
.sp 9p
.RT
.PP
11.2.1
The bits in the bitstring, commencing with the first bit and
proceeding to the trailing bit, shall be placed in bits\ 8 to\ 1 of the first
subsequent octet, followed by bits\ 8 to\ 1 of the second subsequent octet,
followed by bits\ 8 to\ 1 of each octet in turn, followed by as many bits
as are needed of the final subsequent octet, commencing with bit\ 8.
.PP
\fINote\fR \ \(em\ The notation \*Qfirst bit\*U and \*Qtrailing bit\*U
is specified in Recommendation\ X.208.
.PP
11.2.2
The initial octet shall encode, as an unsigned binary integer with bit\
1 as the least significant bit, the number of unused bits in the final
subsequent octet. The number shall be in the range zero to seven.
.sp 9p
.RT
.PP
11.2.3
If the bitstring is empty, there shall be no subsequent octets,
and the initial octet shall be zero.
.PP
11.3
The contents octets for the constructed encoding shall consist of the complete
encoding of zero, one or more data values.
.PP
\fINote\fR \ \(em\ Each such encoding includes identifier, length, and
contents octets, and may include end\(hyof\(hycontents octets if it is
constructed.
.PP
11.3.1
Each data value encoding in the contents octets shall be the
encoding of a value of type BIT STRING.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ In particular, the tags in the contents octets are always
universal class, number\ 3.
.PP
11.3.2
The bits in the bitstring value being encoded, commencing with the first
bit and proceeding to the trailing bit, shall be placed in the first bit
up to the trailing bit of the first data value encoded in the contents
octets, followed by the first bit up to the trailing bit of the second
data value
encoded in the contents octets, followed by the first bit up to the trailing
bit of each data value in turn, followed by the first bit up to the trailing
bit of the last data value encoded in the contents octets.
.sp 9p
.RT
.PP
11.3.3
Each data value encoded in the contents octets, with the exception of the
last, shall consist of a number of bits which is a multiple of eight.
.PP
\fINote\fR \ \(em\ A data value encoded in the contents octets may be a
zero\(hylength bitstring.
.PP
11.3.4
Where a constructed encoding is used, there shall be no
significance placed on the boundary between the data values encoded in the
contents octets.
.sp 9p
.RT
.PP
11.3.5
The encoding of each data value encoded in the contents octets may be primitive
or constructed.
.PP
\fINote\fR \ \(em\ It is usually primitive.
.PP
\fIExample\fR \ \(em\ If of type BIT STRING, the value '0A3B5F291CD'H can be
encoded as shown below. In this example, the Bit String is represented as a
primitive:
.RT
.LP
BitString
Length
Contents
.LP
03\d1\\d6\u 07\d1\\d6\u 040A3B5F291CD0\d1\\d6\u.bp
.PP
The value shown above can also be encoded as shown below. In this example,
the Bit String is represented as a constructor:
.ce
\fBH.T. [T5.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(30p) | lw(24p) | lw(30p) .
BitString \fILength\fR \fIContents\fR
.T&
lw(30p) | lw(24p) | lw(30p) .
23 1 6 80 1 6
.T&
lw(30p) | lw(24p) | lw(30p) .
BitString \fILength\fR \fIContents\fR
.T&
lw(30p) | lw(24p) | lw(30p) .
03 1 6 03 1 6 000A3B 1 6
.T&
lw(30p) | lw(24p) | lw(30p) .
BitString \fILength\fR \fIContents\fR
.T&
lw(30p) | lw(24p) | lw(30p) .
03 1 6 05 1 6 045F291CD0 1 6
.T&
lw(30p) | lw(24p) | lw(30p) .
EOC \fILength\fR
.T&
lw(30p) | lw(24p) | lw(30p) .
00 1 6 00 1 6
.TE
.nr PS 9
.RT
.ad r
\fBTable [T5.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB12\fR \fBEncoding of an octetstring value\fR
.sp 1P
.RT
.PP
12.1
The encoding of an octetstring value shall be either primitive or constructed
at the option of the sender.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ Where it is necessary to transfer part of an octet string
before the entire octetstring is available, the constructed encoding is
used.
.PP
12.2
The primitive encoding contains zero, one or more contents octets equal
in value to the octets in the data value, in the order they appear in the
data value, and with the most significant bit of an octet of the data value
aligned with the most significant bit of an octet of the contents octets.
.sp 9p
.RT
.PP
12.3
The contents octets for the constructed encoding shall consist of the complete
encoding of zero, one or more data values.
.PP
\fINote\fR \ \(em\ Each such encoding includes identifier, length, and
contents octets, and may include end\(hyof\(hycontents octets if it is
constructed.
.PP
12.3.1
Each data value encoding in the contents octets shall be the
encoding of a value of type octetstring.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ In particular, the tags in the contents octets are always
universal class, number\ 4.
.PP
12.3.2
The octets in the octetstring value being encoded, commencing with the
first octet and proceeding to the trailing octet, shall be placed in the
first up to the trailing octet of the first data value encoded in the contents
octets, followed by the first up to the trailing octet of the second data
value encoded in the contents octets, followed by the first up to the trailing
octet of each data value in turn, followed by the first up to the trailing
octet of the last data value encoded in the contents octets.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ A data value encoded in the contents octets may be a
zero length octet string.
.PP
12.3.3
Where a constructed encoding is used, there shall be no
significance placed on the boundary between the data values encoded in the
contents octets.
.sp 9p
.RT
.PP
12.3.4
The encoding of each data value encoded in the contents octets may be primitive
or constructed.
.PP
\fINote\fR \ \(em\ It is usually primitive.
.sp 2P
.LP
\fB13\fR \fBEncoding of a null value\fR
.sp 1P
.RT
.PP
13.1
The encoding of a null value shall be primitive.
.sp 9p
.RT
.PP
13.2
The contents octets shall not contain any octets.
.PP
\fINote\fR \ \(em\ The length octet is zero.
.LP
\fIExample\fR \ \(em\ If of type NULL, the NULL can be encoded as:
.ce
\fBH.T. [T6.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(24p) | lw(36p) .
Null \fILength\fR
.T&
lw(24p) | lw(36p) .
05 1 6 00 1 6
.TE
.nr PS 9
.RT
.ad r
\fBTable [T6.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB14\fR \fBEncoding of a sequence value\fR
.sp 1P
.RT
.PP
14.1
The encoding of a sequence value shall be constructed.
.sp 9p
.RT
.PP
14.2
The contents octets shall consist of the complete encoding of one data
value from each of the types listed in the ASN.1 definition of the
sequence type, in the order of their appearance in the definition, unless
the type was referenced with the keyword \*QOPTIONAL\*U or the keyword
\*QDEFAULT\*U.
.PP
14.3
The encoding of a data value may, but need not, be present for a type which
was referenced with the keyword \*QOPTIONAL\*U or the keyword \*QDEFAULT\*U.
If present, it shall appear in the encoding at the point corresponding
to the appearance of the type in the ASN.1 definition.
.LP
\fIExample\fR \ \(em\ If of type
.LP
SEQUENCE {name IA5String, ok BOOLEAN}
.LP
the value
.LP
{name \*QSmith\*U, ok TRUE}
.LP
can be encoded as:
.LP
.sp 1
.ce
\fBH.T. [T7.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(24p) | lw(24p) | lw(24p) .
Sequence \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(24p) | lw(24p) .
30 1 6 0A 1 6
.T&
lw(24p) | lw(24p) | lw(30p) .
IA5String \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(24p) | lw(30p) .
16 1 6 05 1 6 \*QSmith\*U
.T&
lw(24p) | lw(24p) | lw(30p) .
Boolean \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(24p) | lw(30p) .
01 1 6 01 1 6 FF 1 6
.TE
.nr PS 9
.RT
.ad r
\fBTable [T7.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
.sp 1
\fB15\fR \fBEncoding of a sequence\(hyof value\fR
.sp 1P
.RT
.PP
15.1
The encoding of a sequence\(hyof value shall be constructed.
.sp 9p
.RT
.PP
15.2
The contents octets shall consist of zero, one or more complete
encodings of data values from the type listed in the ASN.1 definition.
.PP
15.3
The order of the encodings of the data values shall be the same as the
order of the data values in the sequence\(hyof value to be encoded.
.sp 2P
.LP
\fB16\fR \fBEncoding of a set value\fR
.sp 1P
.RT
.PP
16.1
The encoding of a set value shall be constructed.
.sp 9p
.RT
.PP
16.2
The contents octets shall consist of the complete encoding of a
data value from each of the types listed in the ASN.1 definition of the set
type, in an order chosen by the sender, unless the type was referenced
with the keyword \*QOPTIONAL\*U or the keyword \*QDEFAULT\*U.
.PP
16.3
The encoding of a data value may, but need not, be present for a type which
was referenced with the keyword \*QOPTIONAL\*U or the keyword
\*QDEFAULT\*U.
.PP
\fINote\fR \ \(em\ The order of data values in a set value is not
significant, and places no constraints on the order during transfer.
.sp 2P
.LP
\fB17\fR \fBEncoding of a set\(hyof value\fR
.sp 1P
.RT
.PP
17.1
The encoding of a set\(hyof value shall be constructed.
.sp 9p
.RT
.PP
17.2
The text of \(sc\ 15.2 applies.
.PP
17.3
The order of data values need not be preserved by the encoding and subsequent
decoding.
.bp
.sp 2P
.LP
\fB18\fR \fBEncoding of a choice value\fR
.sp 1P
.RT
.PP
The encoding of a choice value shall be the same as the encoding of a value
of the chosen type.
.PP
\fINote\ 1\fR \ \(em\ The encoding may be primitive or constructed depending
on the chosen type.
.PP
\fINote\ 2\fR \ \(em\ The tag used in the identifier octets is the tag of the
chosen type, as specified in the ASN.1 definition of the choice type.
.RT
.sp 2P
.LP
\fB19\fR \fBEncoding of a selection value\fR
.sp 1P
.RT
.PP
The encoding of a selection value shall be the same as the encoding of
a value of the selected type.
.PP
\fINote\fR \ \(em\ The encoding may be primitive or constructed depending
on the selected type.
.RT
.sp 2P
.LP
\fB20\fR \fBEncoding of a tagged value\fR
.sp 1P
.RT
.PP
20.1
The encoding of a tagged value shall be derived from the complete encoding
of the corresponding data value of the type appearing in the
\*QTaggedType\*U notation (called the base encoding) as specified in \(sc\
20.2 and
\(sc\ 20.3.
.sp 9p
.RT
.PP
20.2
If the \*QIMPLICIT\*U keyword was not used in the definition of the
type, the encoding shall be constructed and the contents octets shall be the
complete base encoding.
.PP
20.3
If the \*QIMPLICIT\*U keyword was used in the definition of the type, then
.LP
a)
the encoding shall be constructed if the base encoding is
constructed, and shall be primitive otherwise; and
.LP
b)
the contents octets shall be the same as the contents octets of the base
encoding.
.LP
\fIExample\fR \ \(em\ With ASN.1 type definitions of
.LP
Type1 ::=
VisibleString
.LP
Type2 ::=
[APPLICATION 3] IMPLICIT Type1
.LP
Type3 ::=
[2] Type2
.LP
Type4 ::=
[APPLICATION 7] IMPLICIT Type3
.LP
Type5 ::=
[2] IMPLICIT Type2
.LP
a value of
.LP
\*QJones\*U
.LP
is encoded as follows:
.ce
\fBH.T. [T8.209]\fR
.ce
For Type1:
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(42p) | lw(30p) | lw(42p) .
VisibleString \fILength\fR \fIContents
.T&
lw(42p) | lw(30p) | lw(42p) .
1A 1 6 05 1 6 4A6F6E6573 1 6
.T&
lw(174p) .
For Type2:
.T&
lw(42p) | lw(30p) | lw(42p) .
[Application 3] \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(30p) | lw(42p) .
43 1 6 05 1 6 4A6F6E6573 1 6
.T&
lw(174p) .
For Type3:
.T&
lw(42p) | lw(30p) | lw(42p) .
[2] \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(30p) | lw(42p) .
A2 1 6 07 1 6
.T&
lw(42p) | lw(30p) | lw(42p) .
[Application 3] \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(30p) | lw(42p) .
43 1 6 05 1 6 4A6F6E6573 1 6
.T&
lw(174p) .
For Type4:
.T&
lw(42p) | lw(30p) | lw(42p) .
[Application 7] \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(30p) | lw(42p) .
67 1 6 07 1 6
.T&
lw(42p) | lw(30p) | lw(42p) .
[Application 3] \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(30p) | lw(42p) .
43 1 6 05 1 6 4A6F6E6573 1 6
.T&
lw(174p) .
For Type5:
.T&
lw(42p) | lw(30p) | lw(42p) .
[2] \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(30p) | lw(42p) .
82 1 6 05 1 6 4A6F6E6573 1 6
.TE
.nr PS 9
.RT
.ad r
\fBTable [T8.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB21\fR \fBEncoding of a value of the ANY type\fR
.sp 1P
.RT
.PP
The encoding of an ANY type shall be the complete encoding
specified in this Recommendation for the type of the value of the ANY
type.
.RT
.sp 2P
.LP
\fB22\fR \fBEncoding of an object identifier value\fR
.sp 1P
.RT
.PP
22.1
The encoding of an object identifier value shall be primitive.
.sp 9p
.RT
.PP
22.2
The contents octets shall be an (ordered) list of encoding of
subidentifiers (see \(sc\ 22.3 and \(sc\ 22.4) concatenated together.
.PP
Each subidentifier is represented as a series of (one or more)
octets. Bit 8 of each octet indicates whether it is the last in the series:
bit\ 8 of the last octet is zero; bit\ 8 of each preceding octet is one.
Bits\ 7\(hy1 of the octets in the series collectively encoded the subidentifier.
Conceptually, these groups of bits are concatenated to form an unsigned
binary number whose most significant bit is bit\ 7 of the first octet and
whose least significant bit is bit\ 1 of the last octet. The subidentifier
shall be encoded in the fewest possible octets, that is, the leading octet
of the subidentifier shall not have the value\ 80 (hexadecimal).
.PP
22.3
The number of subidentifiers (N) shall be one less than
the number of object identifier components in the object identifier value
being encoded.
.sp 9p
.RT
.PP
22.4
The numerical value of the first subidentifier is derived from the values
of the first two object identifier components in the object identifier
value being encoded, using the formula
\v'6p'
.sp 1P
.ce 1000
(X\|*\|40) + Y
.ce 0
.sp 1P
.LP
.sp 1
where X is the value of the first object identifier component
and Y is the value of the second object identifier component.
.PP
\fINote\fR \ \(em\ This packing of the first two object identifier
components
recognises that only three values are allocated from the root node, and at
most\ 39 subsequent values from nodes reached by X\ =\ 0 and X\ =\ 1.
.PP
22.5
The numerical value of the i'th subidentifier,
(2\ \(=\ i\ \(=\ N) is that of the (i\ +\ 1)'th object identifier component.
.sp 9p
.RT
.LP
\fIExample\fR \ \(em\ An OBJECT IDENTIFIER value of
.LP
{joint\(hyiso\(hyccitt\ 100\ 3}
.LP
which is the same as
.LP
{2\ 100\ 3}
.LP
has a first subidentifier of 180 and a second subidentifier
of\ 3. The resulting encoding is
.ce
\fBH.T. [T9.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(48p) | lw(24p) | lw(36p) .
OBJECT IDENTIFIER \fILength\fR \fIContents\fR
.T&
lw(48p) | lw(24p) | lw(36p) .
06 1 6 03 1 6 813403 1 6
.TE
.nr PS 9
.RT
.ad r
\fBTable [T9.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB23\fR \fBEncoding for values of the character string types\fR
.sp 1P
.RT
.PP
23.1
The data value consists of a string of characters from the
character set specified in the ASN.1 type definition.
.sp 9p
.RT
.PP
23.2
Each data value shall be encoded independently of other data
values of the same type.
.PP
23.3
Each character string type shall be encoded as if it had been
declared
.sp 1P
.ce 1000
[UNIVERSAL x] IMPLICIT OCTET STRING
.ce 0
.sp 1P
.LP
where x is the number of the universal class tag assigned to the
character string type in Recommendation\ X.208. The value of the octet
string is specified in \(sc\(sc\ 23.4 and\ 23.5.
.PP
23.4
Where a character string type is specified in Recommendation X.208 by direct
reference to an enumerating table (NumericString and
PrintableString), the value of the octet string shall be that specified in
\(sc\ 23.5 for a VisibleString type with the same character string value.
.bp
.sp 9p
.RT
.PP
23.5
The octet string shall contain the octets specified in ISO 2022
for encodings in an 8\(hybit environment, using the escape sequence and
character codings registered in accordance with ISO\ 2375.
.PP
23.5.1
An escape sequence shall not be used unless it is one of those
specified by one of the registration numbers used to define the character
string type in Recommendation\ X.208.
.ce
\fBH.T. [T10.209]\fR
.ce
TABLE\ 2/X.209
.ce
\fBUse of escape sequences\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(48p) | cw(36p) | cw(36p) | cw(72p) | cw(36p) .
Type T{
Assumed G0 (Registration number)
T} T{
Assumed C0 & C1 (Registration number)
T} T{
Assumed escape sequence(s) and locking shift
(where applicable)
T} T{
Explicit escape sequences
allowed?
T}
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
NumericString 2 None ESC\ 2/8\ 4/0\ LS0 NO
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
PrintableString 2 None ESC\ 2/8\ 4/0\ LS0 NO
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
TeletexString (T61String) 102 106(C0) 107(C1) T{
ESC\ 2/8\ 7/5\ LS0
ESC\ 2/1\ 4/5
ESC\ 2/2\ 4/8
T} YES
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
VideotexString 102 1(C0) 73(C1) T{
ESC\ 2/8\ 7/5\ LS0
ESC\ 2/1\ 4/0
ESC\ 2/2\ 4/1
T} YES
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
VisibleString (ISO646String) 2 None ESC\ 2/8\ 4/0\ LS0 NO
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
IA5String 2 1(C0) T{
ESC\ 2/8\ 4/0\ LS0
ESC\ 2/1\ 4/0
T} NO
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
GraphicString 2 None ESC\ 2/8\ 4/0\ LS0 YES
_
.T&
lw(48p) | cw(36p) | cw(36p) | lw(72p) | cw(36p) .
GeneralString 2 1(C0) ESC\ 2/8\ 4/0\ LS0 ESC\ 2/1 T{
YES
\fINote\fR
\ \(em\ Many of the commonly used characters (for example, A
to Z) appear in a number of character repertoires with individual
registration numbers and escape sequences. Where ASN.1 types allow
escape sequences, a number of encodings may be possible for a
particular character string (see also\ \(sc\ 5.3).
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable [T10.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
23.5.2
At the start of each string, certain registration numbers shall be assumed
to be designated as G0 and/or C0 and/or C1, and invoked (using the
terminology of ISO\ 2022). These are specified for each type in Table\
2/X.209, together with the assumed escape sequence they imply.
.PP
23.5.3
Certain character string types shall not contain explicit escape sequences
in their encodings; in all other cases, any escape allowed by
\(sc\ 23.5.1 can appear at any time, including at the start of the encoding.
Table\ 2/X.209 lists the types for which explicit escape sequences are allowed.
.PP
23.5.4
Announcers shall not be used unless explicitly permitted by the
user of ASN.1.
.PP
\fINote\fR \ \(em\ The choice of ASN.1 type provides a limited form of
announcer functionality. Specific application protocols may choose to carry
announcers in other protocol elements, or to specify in detail the manner of
use of announcers.
.bp
.LP
\fIExample\fR \ \(em\ With the ASN.1 type definition
.LP
Name ::= VisibleString
.ce
\fBH.T. [T11.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(168p) .
a value
.T&
lw(168p) .
\*QJones\*U
.T&
lw(168p) .
T{
can be encoded (primitive form) as
T}
.T&
lw(42p) | lw(24p) | lw(42p) .
VisibleString \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
1A 1 6 05 1 6 4A6F6E6573 1 6
.T&
lw(168p) .
T{
or (constructor form, definite length), as:
T}
.T&
lw(42p) | lw(24p) | lw(42p) .
VisibleString \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
3A 1 6 09 1 6
.T&
lw(42p) | lw(24p) | lw(42p) .
OctetString \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
04 1 6 03 1 6 4A6F6E 1 6
.T&
lw(42p) | lw(24p) | lw(42p) .
OctetString \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
04 1 6 02 1 6 6573 1 6
.T&
lw(168p) .
T{
or (constructor form, indefinite length), as:
T}
.T&
lw(42p) | lw(24p) | lw(42p) .
VisibleString \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
3A 1 6 80 1 6
.T&
lw(42p) | lw(24p) | lw(42p) .
OctetString \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
04 1 6 03 1 6 4A6F6E 1 6
.T&
lw(42p) | lw(24p) | lw(42p) .
OctetString \fILength\fR \fIContents\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
04 1 6 02 1 6 6573 1 6
.T&
lw(42p) | lw(24p) | lw(42p) .
EOC \fILength\fR
.T&
lw(42p) | lw(24p) | lw(42p) .
00 1 6 00 1 6
.TE
.nr PS 9
.RT
.ad r
\fBTable [T11.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
The above example illustrates three of the (many) possible forms available
as a sender's option. Receivers are required to handle all permitted forms
(see \(sc\ 5.3).
.sp 2P
.LP
\fB24\fR \fBEncoding for values of the ASN.1 useful types\fR
.sp 1P
.RT
.PP
A definition of these types using ASN.1 is provided in
Recommendation\ X.208. The encoding shall be that obtained by applying
the rules specified in this Recommendation to that type definition.
.RT
.sp 2P
.LP
\fB25\fR \fBUse in transfer syntax definition\fR
.sp 1P
.RT
.PP
25.1
The encoding rules specified in this Recommendation can be
referenced and applied whenever there is a need to specify an unambiguous,
undivided and self\(hydelimiting octet string representation for all of
the values of a single ASN.1 type.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ All such octet strings are unambiguous within the scope
of the single ASN.1 type. They would not necessarily be unambiguous if
mixed
with encodings of a different ASN.1 type.
.PP
25.2
The object identifier and object descriptor values
.sp 9p
.RT
.LP
{joint\(hyiso\(hyccitt asn1 (1) basic\(hyencoding\ (1)}
.LP
and
.LP
\*QBasic Encoding of a single ASN.1 type\*U
.LP
are assigned to identify and describe the encoding rules specified in
this Recommendation.
.PP
25.3
Where an application specification defines an abstract syntax
as a set of presentation data values, each of which is a value of some
specifically named ASN.1 type, usually (but not necessarily) a choice type,
then the object identifier value specified in \(sc\ 25.2 may be used with the
abstract syntax name to identify that transfer syntax which results from the
application of the encoding rules specified in this Recommendation to the
specifically named ASN.1 type used in defining the abstract syntax.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ In particular, this identification of the encoding rules
can appear in the \*Qtransfer syntax name\*U field of the presentation
protocol
(Recommendation\ X.226).
.bp
.PP
25.4
The name specified in \(sc 25.2 shall not be used with an abstract
syntax name to identify a transfer syntax if the conditions of \(sc\ 25.3 for
the definition of the abstract syntax are not met.
\v'1P'
.sp 9p
.RT
.ce 1000
APPENDIX\ I
.ce 0
.ce 1000
(to Recommendation X.209)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExample of encodings\fR
.sp 1P
.RT
.ce 0
.PP
This appendix illustrates the basic encoding rules specified in
this Recommendation by showing the representation in octets of a (hypothetical)
personnel record which is defined using ASN.1.
.sp 1P
.RT
.sp 1P
.LP
I.1
\fIASN.1 description of the record structure\fR
.sp 9p
.RT
.PP
The structure of the hypothetical personnel record is formally
described below using ASN.1 specified in Recommendation\ X.208 for defining
types.
.RT
.LP
PersonnelRecord ::= [APPLICATION 0] IMPLICIT SET
.LP
{
Name,
.LP
\ title
[0] VisibleString,
.LP
\ number
EmployeeNumber,
.LP
\ dateOfHire
[1] Date,
.LP
\ nameOfSpouse
[2] Name,
.LP
\ children
[3] IMPLICIT
.LP
SEQUENCE OF ChildInformation
.LP
DEFAULT\ {\|} }
.LP
ChildInformation ::= SET
.LP
{
Name,
.LP
\ dateOfBirth
[0] Date}
.LP
Name ::= [APPLICATION 1] IMPLICIT SEQUENCE
.LP
{givenName
VisibleString,
.LP
\ initial
VisibleString,
.LP
\ familyName
VisibleString}
.LP
EmployeeNumber ::= [APPLICATION 2] IMPLICIT INTEGER
.LP
Date ::= [APPLICATION 3] IMPLICIT VisibleString
.LP
\ \(hy\(hy\ YYYYMMDD
.sp 1P
.LP
I.2
\fIASN.1 description of a record value\fR
.sp 9p
.RT
.PP
The value of John Smith's personnel record is formally described
below using ASN.1.
.RT
.LP
{
{givenName \*QJohn\*U,initial \*QP\*U,familyName \*QSmith\*U},
.LP
\ title
\*QDirector\*U,
.LP
\ number
51,
.LP
\ dateOfHire
\*Q19710917\*U,
.LP
\ nameOfSpouse
{givenName \*QMary\*U,initial \*QT\*U,familyName \*QSmith\*U},
.LP
\ children
.LP
\ \ {{{givenName \*QRalph\*U,initial \*QT\*U,familyName \*QSmith\*U},
.LP
\ \ \ \ \ dateOfBirth \*Q19571111\*U},
.LP
\ \ \ \ \ {{givenName \*QSusan\*U,initial \*QB\*U,familyName \*QJones\*U},
.LP
\ \ \ \ \ \ dateOfBirth \*Q19590717\*U}}}
.sp 1P
.LP
I.3
\fIRepresentation of this record value\fR
.sp 9p
.RT
.PP
The representation in octets of the record value given above (after applying
the basic encoding rules defined in this Recommendation) is shown
below. The values of identifiers, lengths, and the contents of integers are
shown in hexadecimal, two hexadecimal digits per octet. The values of the
contents of character strings are shown as text, one character per octet.
.bp
.RT
.ce
\fBH.T. [T12.209]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(31p) | lw(19p) | lw(24p) .
Personnel Record 60 . \fILength\fR 8185 . \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Name \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
61 10
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
1A 04 \*QJohn\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
1A 01 \*QP\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
1A 05 \*QSmith\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Title \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
A0 0A
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
1A 08 \*QDirector\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Employee Number 42 . \fILength\fR 01 . \fIContents\fR 33
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Date of Hire A1 . \fILength\fR 0A . \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Date \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
43 08 \*Q19710917\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Name of Spouse A2 . \fILength\fR 12 . \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Name \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
61 10
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
1A 04 \*QMary\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
1A 01 \*QT\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
1A 05 \*QSmith\*U
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
[3] \fILength\fR \fIContents\fR
.T&
lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) .
A3 42
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Set \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
31 1F
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Name \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
61 11
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
1A 05 \*QRalph\*U
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
1A 01 \*QT\*U
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
1A 05 \*QSmith\*U
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Date of Birth A0 . \fILength\fR 0A . \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Date \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
43 08 \*Q19571111\*U
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Set \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
31 1F
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Name \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
61 11
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
16 05 \*QSusan\*U
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
16 01 \*QB\*U
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Visible\(hyString \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
1 05 \*QJones\*U
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Date of Birth A0 . \fILength\fR 0A . \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
Date \fILength\fR \fIContents\fR
.T&
lw(18p) | lw(19p) | lw(24p) | lw(19p) | lw(18p) | lw(19p) | lw(18p) .
43 08 \*Q19590717\*U
.TE
.nr PS 9
.RT
.ad r
\fBTable [T12.209], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce 1000
APPENDIX\ II
.ce 0
.ce 1000
(to Recommendation X.209)
.sp 9p
.RT
.ce 0
.ce 1000
\fBAssignment of object identifier values\fR
.sp 1P
.RT
.ce 0
.PP
The following values are assigned in this Recommendation:
.sp 1P
.RT
.LP
\fBClause\fR
\fBObject Identifier Value\fR
.LP
\fBObject Descriptor Value\fR
.LP
25.2
{joint\(hyiso\(hyccitt asn1 (1) basic\(hyencoding (1)}
.LP
\*QBasic Encoding of a single ASN.1 type\*U
\v'1P'
.ce 1000
APPENDIX\ III
.ce 0
.ce 1000
(to Recommendation X.209)
.sp 9p
.RT
.ce 0
.ce 1000
\fBIllustration of real value encoding\fR
.sp 1P
.RT
.ce 0
.PP
III.1
A sender will normally examine his own hardware floating point
representation to determine the (value\(hyindependent) algorithms to be used to
transfer values between this floating\(hypoint representation and the length
and contents octets of the encoding of an ASN.1 real value. This Appendix
illustrates the steps which would be taken in such a process by using the
(artificial) hardware floating point representation of the mantissa shown in
Figure\ III\(hy1/X.209.
.sp 1P
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure III\(hy1/X.209, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
It is assumed that the exponent can easily be obtained from the
floating point hardware as an integer value\ E.
.PP
III.2
The contents octets which need to be generated for sending a
non\(hyzero value (as specified in the body of this Recommendation) are:
\v'6p'
.sp 9p
.RT
.sp 1P
.ce 1000
1 S bb ff ee\ \ \ Octets for E\ \ \ Octets for N
.ce 0
.sp 1P
.LP
.sp 1
where S (the mantissa sign) is dependent on the value to be
converted, bb is a fixed value (say\ 10) to represent the base (in this
case let us assume base\ 16), ff is the fixed\ F vaue calculated as described
in
\(sc\ III.3, and ee is a fixed length of exponent value calculated as described
in \(sc\ III.4 (this Appendix does not treat the case where E needs to exceed
three octets).
.bp
.PP
III.3
The algorithm will transmit octets 1 to 5 of the hardware
representation as the value of N, after forcing bits\ 8 to\ 3 of octet\ 1 and
bits\ 4 to\ 1 of octet\ 5 to zero. The implied decimal point is assumed to be
positioned between bits\ 2 and\ 1 of octet in the hardware representation
which delivers the value of\ E. Its implied position can be shifted to
the nearest
point after the end of octet\ 6 by reducing the value of\ E before
transmission. In our example system we can shift by four bits for every
exponent decrement (because we are assuming base\ 16), so a decrement of\
9 will position the implied point between bits\ 6 and\ 5 of octet\ 6. Thus
the value of M is N multiplied by\ 2\u3\d to position the point correctly
in\ M. (The
implied position\ N, the octets transferred, is after bit\ 1 of octet\ 5.) Thus
we have the crucial parameters:
.sp 9p
.RT
.LP
F\ =\ 3\ (so ff is 11)
.LP
exponent decrement = 9
.PP
III.4
The length needed for the exponent is now calculated by working
out the maximum number of octets needed to represent the values
\v'6p'
.sp 9p
.RT
.ce 1000
E\dm\\di\\dn\u\ \(em\ excess\ \(em\ exponent decrement
.ce 0
.sp 1P
.ce 1000
E\dm\\da\\dx\u\ \(em\ excess\ \(em\ exponent decrement
.ce 0
.sp 1P
.LP
.sp 1
where E\dm\\di\\dn\uand E\dm\\da\\dx\uare minimum and maximum
integer values of the exponent representation, excess is any value which
needs subtracting to produce the true exponent value, and the exponent
decrement is as calculated in \(sc\ III.3. Let us assume this gives a length
of 3\ octets. Then ee is\ 10. Let us also assume excess is zero.
.PP
III.5
The transmission algorithm is now:
.sp 9p
.RT
.LP
a)
test for zero, and if so, transmit an ASN.1 length of zero
(no contents octets) and end the algorithm;
.LP
b)
test and remember the mantissa sign, and negate the mantissa
if negative;
.LP
c)
transmit an ASN.1 length of 9, then
.ce 1000
11101110\ \ if negative
.ce 0
.LP
or
.sp 1P
.ce 1000
10101110\ \ if positive
.ce 0
.sp 1P
.LP
d)
produce and transmit the 3 octet exponent with value
.sp 1P
.ce 1000
E \(em 9
.ce 0
.sp 1P
.LP
e)
zero bits 8 to 3 of octet 1 and bits 4 to 1 of octet 5, then
transmit the 5 octet mantissa.
.PP
III.6
The receiving algorithm has to be prepared to handle any ASN.1
format, but here the floating point unit can be directly used. We proceed as
follows:
.sp 9p
.RT
.LP
a)
check octet 1 of the contents; if it is 1x101110 we have
a transmission compatible with ours, and can simply reverse the
sending algorithm;
.LP
b)
otherwise, for character encoding invoke standard character
decimal to floating point conversion software, and deal with a
\*QSpecialRealValue\*U according to the application semantics (perhaps
setting the largest and smallest number the hardware floating point
can handle);
.LP
c)
for a binary transmission, put N into the floating point
unit, losing octets at the least significant end if necessary, multiply
by 2\uF\d, and by B\uE\d, then negate if necessary. Implementors may
find optimisation possible in special cases, but may find (apart from
the optimisation relating to transmissions from a compatable machine)
that testing for them loses more than they gain.
.PP
III.7
The above algorithms are illustrative only. Implementors will, of course,
determine their own best strategies.
.sp 9p
.RT
.LP
.bp
.LP
\fBMONTAGE:\ \fR PAGE 152 = PAGE BLANCHE
.sp 1P
.RT
.LP
.bp